Dotaz: Monitoring procesu s dynamickým PID

[Petr]

Dobrý den.
Potřeboval bych pomoct se zajištěním monitoringu procesu.
V podstate volám ffmpeg s nějakými parametry. Po zavolání a spuštění procesu na pozadí potřebuju vědět, zda-li proces běží nebo neběží a pokud neběží, potřebuju aby se znovu spustil. Zatím nevím, kudy nejlépe do toho.

Příklad

ffmpeg -rtsp_transport tcp -i $RTSP_URL1 -c:v copy -c:a copy -f flv $DEST_URL1 > /var/log/ffmpeg/stream01.log 2>&1 < /dev/null &
ffmpeg -rtsp_transport tcp -i $RTSP_URL2 -c:v copy -c:a copy -f flv $DEST_URL2 > /var/log/ffmpeg/stream02.log 2>&1 < /dev/null &

Nějaký nápad ?
Celé bych to následně rád svěřil systemd.

---

---

Odpovědi

[X]

Odpovedel jsi si sam. Napis si na to demona(unit) v systemd, ktery zajisti restart, logovani, status etc.

[Petr]

Asi by se hodil nějaký exampel...
Mohu poprosit ?

Neříkám "vymysli to za mě". Říkám example, odkaz, zdroj.
Nikdy jsem to nedělal - hraju si.

Děkuji.

[Max]

Něco jako:

nano /etc/systemd/system/ffmpeg.service

[Unit]
Description=FFmpeg service
After=multi-user.target sound.target network-online.target

[Service]
Type=simple
User=uzivatel
Group=skupina
WorkingDirectory=/home/user/
ExecStart=/home/user/ffmpeg-script.sh
Restart=always

[Install]
WantedBy=default.target


systemctl daemon-reload
systemctl enable ffmpeg
systemctl start ffmpeg

Nemám odzkoušeno, jen střílím.
Zdar Max

[Ruža Becelin]

Jeste tip:

systemctl enable ffmpeg
systemctl start ffmpeg

lze nahradit

systemctl enable ffmpeg --now

[fe]

Ta náhrada funguje jen v novějších distrech (novějších verzích systemd).

[Ruža Becelin]

To jsou dneska vsechny podporovane, ne?

[Petr]

Děkuji za rady.
Spíš tedy potřebuju řešit, jak ošetřit, že jeden ffmpeg běží a druhý že spadnul, což bych měl teda řešit na úrovni skriptu, který bude ten ffmpeg spouštět nebo na úrovni systemd ?

Skript by zatím vypadal takto

ffmpeg -rtsp_transport tcp -i $RTSP_URL1 -c:v copy -c:a copy -f flv $DEST_URL1 > /var/log/ffmpeg/stream01.log 2>&1 < /dev/null &
ffmpeg -rtsp_transport tcp -i $RTSP_URL2 -c:v copy -c:a copy -f flv $DEST_URL2 > /var/log/ffmpeg/stream02.log 2>&1 < /dev/null &

..a je tedy potřeba ošetřit, že když spadne process ffmpegu pro kameru1, tak že se restartuje jen proces pro kameru1 a totéž úplně stejně pro kameru2 až kameruN. V žádném případě ale nesmí dojít ke spuštění procesu pro kameruX vícekrát, tedy duplicitně.

Takže teď v tom mám ještě větší hokej.
Nebo právě tohle bude hlídat systemd "samo" ?

Děkuji.

[X]

Pro kazdou kameru si vytvor samostatny unit soubor cam1.service, cam2.service.. Asi by se dal ten ffmpeg poustet i primo:

RunExec=/usr/bin/ffmpeg -rtsp_transport tcp -i $RTSP_URL1 -c:v copy -c:a copy -f flv $DEST_URL1

to logovani a pousteni na pozadi:

 > /var/log/ffmpeg/stream01.log 2>&1 < /dev/null &

muzes vynechat. Logovat za tebe bude systemd a na pozadi to pobezi automaticky:

systemctl status cam1.service
journalctl -u cam1.service

[X]

Ten restart uz tam mas od Maxe:

Restart=always

Nez se zacnes zase ptat tak se pred tim zkus podivat do manualu a na miliardu navodu na internetu ok?

[Jendа]

Může použít takové ty parametry unit, kdy se udělá jedna unita a pak se to spouští jako kamera@parametr.service.

Logování do journalu mě zklamalo, je to 10x větší a šílené pomalé když to člověk listuje. Ale třeba se to dá poladit a takhle blbý je jenom default v Debianu. A pak se mi taky nepodařilo najít jak čistit logy pro různé unity s různým intervalem, třeba když se jedna zblázní a zaplní disk, nebo si naopak chci nějakou zachovat pro pozdější ladění. [1, 2]

[Max]

Tak úplně nejjednodušší je mít dvě unity, pro každou kameru jednu.
Pokud si tedy vezmeš ten příklad výše, tak se ta unita nemusí jmenovat ffmpeg.service, ale cam1.service, cam2.service atd. a v každé volat jiný skript / příkaz jen pro tu konkrétní kameru.
O fous složitější na pochopení je mít unitu jednu a dávat jí parametry kamer.
Zdar Max

[Petr]

Díky moc.
Tohle je asi to, co by mě nejvíc zajímalo. Kamer bude víc, tak by se spíše hodila tato cesta...

Petr