PID vinden of opslaan om te killen

[sjongenelen]

Ik probeer al een tijdje het volgende:

ik heb een ffmpeg proces runnen op mn NAS (linux bak), die heel de dag die films transcode. _{vraag me niet waarom..}
Dit is prima, echter, wanneer ik wil streamen vanuit deze NAS naar mn TV, wordt een 2e ffmpeg proces gestart, die een film 'on the fly' transcode. Op dat moment moet hij dus het 1e ffmpeg thread het commando 'kill -sigstop 12345' geven _{(waar 12345 het PIDnr is van de 1e PID)}. Dit omdat de CPU niet sterk genoeg is voor beide tegelijk...!

nu komt het probleem; ik weet het PID van het eerste ffmpeg thread niet. Als ik top of ps doe, dan zie ik prima welke ik moet killen (aan de parameters van het programma), maar ik kan geen ps grep of pidof doen aangezien die twee resultaten teruggeeft...

kan ik:

- bij het starten van het ffmpeg commando gelijk de PID ergens wegschrijven (dit doet hij zelf niet nl.), cronjob draaien elke 10 seconden? Om te checken of er twee ffmpeg processen actief zijn, zo ja, SIGSTOP de eerste transcoder- zo nee, SIGCONT hem?

- het anders doen? via een cronjob elke 10 seconden scannen is natuurlijk niet ideaal, maar ik kan me niet voorstellen dat het makkelijk is om een soort hook te maken op de synology mediaserver die iets uitvoert zodra hij ziet dat hij een film moet gaan streamen?

[Anoniem: 32925]

Is dat ding niet gewoon (eenmalig) thumbnails aan het genereren van je foto's oid? Dat kun je pauzeren in DSM.

[sjongenelen]

Anoniem: 32925 schreef op woensdag 28 september 2011 @ 19:17:
Is dat ding niet gewoon (eenmalig) thumbnails aan het genereren van je foto's oid? Dat kun je pauzeren in DSM.

nee

edit: misschien een bot antwoord, maar zo is het nou eenmaal

[ Voor 12% gewijzigd door sjongenelen op 28-09-2011 19:30 ]

[Borromini]

Het eerste ffmpeg-proces is ouder en heeft dus een lagere PID. Je kan een scriptje schrijven dat de PIDs checkt en de oudste killt?

Als alternatief kan je ook de prioriteit van het eerste proces verlagen, of uitvissen waar het gestart wordt en dat fiksen .

[ Voor 33% gewijzigd door Borromini op 28-09-2011 19:33 ]

[Hero of Time]

Wat krijg je dan terug als je pidof uitvoert? Heb je niet ergens de optie bij ffmpeg om via parameter --pid-file=/var/run/ffmpeg op te geven oid? En als 't via een script wordt gestart, kill het script, dan wordt ook het proces gekillt.

[blaataaps]

Borromini schreef op woensdag 28 september 2011 @ 19:32:
Het eerste ffmpeg-proces is ouder en heeft dus een lagere PID. Je kan een scriptje schrijven dat de PIDs checkt en de oudste killt?

Pids recyclen.

[Borromini]

Da's ook waar .

[benoni]

Kun je met flock je ffmpeg proces wrappen? Als ik het me goed herinner schrijft flock de PID in een lockfile weg...

Bash:

(
    flock -s 200
    filmpjesencoden.sh
) 200>/var/lock/filmpjesdecoden.lock

[CAPSLOCK2000]

Je zou naar de start-tijd kunnen kijken.

ps -o pid,etime $(pgrep ffmpeg)

Mijn tweede idee is ffmpeg vervangen door een klein scriptje dat eerst kijkt of er al een ffmpeg proces draait en dat dan stop zet.

Mijn derde idee is om het ffmpeg proces dat continue draait te renicen en/of als idle proces te laten draaien (zie man chrt), dan krijgt het alleen processortijd als die over is en gaan andere processen altijd voor.

Het vierde idee is om de eerste ffmpeg in de background te draaien en de shell variabele $! te gebruiken.

ffmpeg bla &
echo $!

[sjongenelen]

okay

-PIDS recyclen idd, geen optie
-ik wil het process niet killen, ik wil kill -SIGSTOP doen. Op deze manier 'pauzeert' het proces. Als ik hem echt kill, stop de film met transcoden (op de helft laten we zeggen) en heb ik er niks aan!
- helaas heeft ffmpeg geen --pid iets, ik hoopte iets met 'echo $! > /volume1/pid.txt' te kunnen doen, maar helaas werkt dat niet op mijn linuxversie, alleen $$ wel

EDIT:

renice klinkt als een goed idee, i.c.m ionice vooral maar goed, hoe geef ik de niceness van een thread wanneer ik 'm start? edit: easy, gewoon starten met nice -n 19 /volume1/script/test.sh dus

edit2:
zie hierboven, $! werkt helaas niet. Flock heb ik nog nooit van gehoord, dus dat ga ik ff googlen
antwoord op flock: werkt helaas niet, hij schrijft niets weg

[ Voor 32% gewijzigd door sjongenelen op 28-09-2011 19:57 ]

[sjongenelen]

CAPSLOCK2000 schreef op woensdag 28 september 2011 @ 19:47:
Je zou naar de start-tijd kunnen kijken.

ps -o pid,etime $(pgrep ffmpeg)

Mijn tweede idee is ffmpeg vervangen door een klein scriptje dat eerst kijkt of er al een ffmpeg proces draait en dat dan stop zet.

Mijn derde idee is om het ffmpeg proces dat continue draait te renicen en/of als idle proces te laten draaien (zie man chrt), dan krijgt het alleen processortijd als die over is en gaan andere processen altijd voor.

Het vierde idee is om de eerste ffmpeg in de background te draaien en de shell variabele $! te gebruiken.

ffmpeg bla &
echo $!

thx !!! ik denk dat het goed werkt als ik m start met 'nice - n 19 /volume1/scripts/test.sh'

wat stom, ik dacht dat je processen alleen kon 're-nicen'


goed, nu even een dagje of wat kijken hoe lang ffmpeg nu over een transcode doet, normaliter zo'n 8x de duur van een video. Hopen dat dat gelijk blijft!

[ Voor 8% gewijzigd door sjongenelen op 28-09-2011 20:00 ]

[Borromini]

TheNymf schreef op woensdag 28 september 2011 @ 19:47:
renice klinkt als een goed idee, i.c.m ionice vooral maar goed, hoe geef ik de niceness van een thread wanneer ik 'm start? edit: easy, gewoon starten met nice -n 19 /volume1/script/test.sh dus

als je het commando met nice opstart:

$ nice rtorrent

dan krijgt het standaard al een lagere prioriteit mee (10).

Was hier in ieder geval de oplossing voor de IO-problemen die gelijktijdig torrenten en streamen met zich meebrachten .

En renice is inderdaad voor al lopende processen .

[ Voor 16% gewijzigd door Borromini op 28-09-2011 20:00 ]

[joker1977]

kill -SIGSTOP $(pgrep ffmpeg)

Misschien is dat iets? Dat zou, in theorie, alle lopende ffmpegs moeten -SIGSTOPPEN (is dat een woord?)

Als het niet werkt, doe eens een

echo $(pgrep ffmpeg) en laat de uitvoer es zien.

[sjongenelen]

joker1977 schreef op woensdag 28 september 2011 @ 19:59:
kill -SIGSTOP $(pgrep ffmpeg)

Misschien is dat iets? Dat zou, in theorie, alle lopende ffmpegs moeten -SIGSTOPPEN (is dat een woord?)

Als het niet werkt, doe eens een

echo $(pgrep ffmpeg) en laat de uitvoer es zien.

mee eens, maar dan SIGSTOP-ed hij ook de film die ik aan het kijken ben


pgrep heb ik niet op deze distro. Als ik pidof (wat volgens mij hetzelfde is en volgens mij krijg ik door een grep op ffmpeg nóg een proces die dat zoekwoord bevat )doe krijg ik dit:
12345 912832

dat zijn dus twee pids van twee threads

[Borromini]

Pgrep zit in het procps-pakket.

[joker1977]

TheNymf schreef op woensdag 28 september 2011 @ 20:03:
[...]


mee eens, maar dan SIGSTOP-ed hij ook de film die ik aan het kijken ben


pgrep heb ik niet op deze distro. Als ik pidof (wat volgens mij hetzelfde is en volgens mij krijg ik door een grep op ffmpeg nóg een proces die dat zoekwoord bevat )doe krijg ik dit:
12345 912832

dat zijn dus twee pids van twee threads

Als je nu dat commando uitvoert vóór dat je de ffmpeg opstart die je film afspeelt is het probleem toch opgelost?

[sjongenelen]

ik wil niet mn laptop moeten pakken, booten, inloggen met putty en dan top, pid onthouden en commando doen als ik een filmpje wil kijken

[Patriot]

TheNymf schreef op woensdag 28 september 2011 @ 21:01:
ik wil niet mn laptop moeten pakken, booten, inloggen met putty en dan top, pid onthouden en commando doen als ik een filmpje wil kijken

Op een gegeven moment ga je streamen, hoe gaat dat precies? Je kunt toch eerst dat commando uitvoeren en dán het streamen pas starten?

[sjongenelen]

ik praat via dlna vanuit de netwerkkaart on de tv naar de nas. uitvoering is wat ik hierboven beschreef. teveel werk dus

[Hero of Time]

Te veel werk om een aanroep van je TV zo aan te passen dat ipv het programma wat normaal je flim start, de draaiende ffmpeg pauzeert en dan pas het programma start, waarna, als het programma klaar is, ffmpeg weer hervat? Even simpel gezegd dit:

code:

#!/bin/bash
# Vervang dit script voor het bestand tvkijken, en hernoem tvkijken naar tvkijken-ffmpeg
kill -SIGSTOP $(pgrep ffmpeg)
/usr/bin/tvkijken-ffmpeg $@
kill -SIGCONT $(pgrep ffmpeg)

Zo moeilijk is het toch niet? Er moet een of andere commando vanuit je TV gestuurd worden met weet ik veel wat voor opties en al. Geef de executable een andere naam, geef je script die naam en hoppa, werken met die hap. $@ is om eventuele argumenten e.d. mee te sturen aan het programma.

Daarbij vraag ik mij af waarom je constant ffmpeg op de achtergrond hebt draaien die films transcode, als je wanneer je TV gaat kijken, ffmpeg weer bezig is met het transcoden. Je zegt wel leuk "vraag me niet waarom", maar dat kan wel je probleem oplossen. Waarom draait ffmpeg überhaupt? Zodat je de transcoded film makkelijk op een draagbare media player kan zetten? Dit zal toch een keer klaar zijn, of issie een week bezig met 1 film (zou leuk zijn voor tv kijken )?

[sjongenelen]

Hero Of Time schreef op woensdag 28 september 2011 @ 23:21:
Te veel werk om een aanroep van je TV zo aan te passen dat ipv het programma wat normaal je flim start, de draaiende ffmpeg pauzeert en dan pas het programma start, waarna, als het programma klaar is, ffmpeg weer hervat? Even simpel gezegd dit:

code:

#!/bin/bash
# Vervang dit script voor het bestand tvkijken, en hernoem tvkijken naar tvkijken-ffmpeg
kill -SIGSTOP $(pgrep ffmpeg)
/usr/bin/tvkijken-ffmpeg $@
kill -SIGCONT $(pgrep ffmpeg)

Zo moeilijk is het toch niet? Er moet een of andere commando vanuit je TV gestuurd worden met weet ik veel wat voor opties en al. Geef de executable een andere naam, geef je script die naam en hoppa, werken met die hap. $@ is om eventuele argumenten e.d. mee te sturen aan het programma.

Daarbij vraag ik mij af waarom je constant ffmpeg op de achtergrond hebt draaien die films transcode, als je wanneer je TV gaat kijken, ffmpeg weer bezig is met het transcoden. Je zegt wel leuk "vraag me niet waarom", maar dat kan wel je probleem oplossen. Waarom draait ffmpeg überhaupt? Zodat je de transcoded film makkelijk op een draagbare media player kan zetten? Dit zal toch een keer klaar zijn, of issie een week bezig met 1 film (zou leuk zijn voor tv kijken )?

- Ik kan de firmware vd TV niet aanpassen nee
- de aanroep afvangen v/d tv op de NAS lijkt mij te ingewikkeld
- mijn tv speelt alleen MPEG2ts en mkv 1920x1080/1270/720 op 23.96fps af via DLNA. Ik converteer alle .avi's naar dit formaat.
-hij is 8x de duur van een film bezig per film.

[CAPSLOCK2000]

TheNymf schreef op woensdag 28 september 2011 @ 23:45:
- de aanroep afvangen v/d tv op de NAS lijkt mij te ingewikkeld

Dat valt reuze mee. Lees de post van Hero of Time nog eens door, die legt het precies uit.

[sjongenelen]

CAPSLOCK2000 schreef op donderdag 29 september 2011 @ 01:36:
[...]
Dat valt reuze mee. Lees de post van Hero of Time nog eens door, die legt het precies uit.

erhm, helemaal niet? Hij schrijft hoe ik ffmpeg pauzeer en weer start (zoals ik nu ook doe), maar niet wáár: wanneer ik via DLNA een film start, zie ik op mijn NAS alleen een 2e ffmpeg thread beginnen die de output direct streamt naar mijn tv. Hoe de Synology NAS dit regelt weet ik niet, ik zie in ieder geval niets gebeuren via het TOP commando.
Ik kan niet de ffmpeg source code aanpassen en dan handmatig compilen/builden voor ARM? (weet niet eens hoe het heet in linux en zeker niet hoe het moet)

Lijkt mij een stuk ingewikkelder dan een shellscript dat nice'd iig

[ Voor 7% gewijzigd door sjongenelen op 29-09-2011 07:52 ]

[frickY]

Je zou ffmpeg kunnen renamen naar ffmpeg_real, en in plaats daarvan een eigen ffmpeg-script neerzetten.
Die kan de argumenten bekijken, daarnaar handelen, en vervolgens de opdracht delegeren naar ffmpeg_real.

Dat is een vrij gebruikelijke manier.

[sjongenelen]

ja maar ffmpeg is geen script maar een programma? dat kan ik toch niet vervangen door een scriptje?

[Anoniem: 26306]

TheNymf schreef op donderdag 29 september 2011 @ 08:04:
ja maar ffmpeg is geen script maar een programma? dat kan ik toch niet vervangen door een scriptje?

Wel hoor. Scriptje executable maken, precies hetzelfde noemen, en dan zorgen dat in het script de "originele" ffmpeg wordt aangeroepen met precies dezelfde argumenten ($@).

[sjongenelen]

hmm, klinkt als een backup oplossing wanneer nice niet werkt. vraag me wel af of het stuk gaat bij updates van ffmpeg

[CAPSLOCK2000]

Dat wel, maar hoe vaak update jij je NAS nu? (misschien onderschat ik dat).

Er is overigens een simpele oplossing. Zet het alternatieve 'ffmpeg' scriptje in /usr/local/bin/

Commando's in /usr/local/bin/ krijgen voorraang over commando's in /usr/bin (die weer voorrang hebben over /bin).

[sjongenelen]

haha, okay thx dat wist ik niet

ik update ffmpeg best vaak, er is bijna elke week wel een update

maar nu ik er over nadenk, DSM lever een versie van ffmpeg mee welke hij gebruikt voor het streamen naar mijn TV. Ik gebruik de nieuwste versie van ffmpeg (via IPKG)

hoe check ik of Synology ook die versie gebruikt, en niet een die in een van zijn eigen folders staat?

in top zie ik geen pad bij het ffmpeg proces...

dit is mijn find result (die in optware is de recente versie binnengehaald via IPKG),
-/opt/bin is een symlink naar /volume1/@optware/bin als ik me niet vergis
-mplayer moet je even niet op letten, die test ik momenteel alleen maar tbv subs via mencoder

Bash:

DiskStation> find / -name ffmpeg
/volume1/@optware/bin/ffmpeg
/volume1/@optware/mplayer/mplayer/ffmpeg
/volume1/@optware/share/ffmpeg
find: /proc/22250/net: Invalid argument
/opt/bin/ffmpeg
/opt/mplayer/mplayer/ffmpeg
/opt/share/ffmpeg
/usr/syno/bin/ffmpeg

mijn beste gok is dat /usr/syno/bin/ffmpeg wordt gebruikt?

als ik 'ffmpeg' tik, krijg ik trouwens een OUDE VERSIE ik zal toch niet al lang de oude versie gebruiken?
als ik /usr/syno/bin/ffmpeg gebruik krijg ik een versie uit 2011

edit: okay, de ipkg updates (http://ipkg.nslu2-linux.o...08q1armel/cross/unstable/) worden dus niet echt bijgewerkt. De versie van ffmpeg daar is uit 2008...

damnn wat stom, maar zo leer ik wel wat meer van linux

okay volgende vraag dus, hoe kom ik aan de nieuwste versie van ffmpeg op mn nas?

[ Voor 56% gewijzigd door sjongenelen op 29-09-2011 13:44 ]

[CAPSLOCK2000]

Kijk eens naar je PATH variabele. Die bevat alle plekken waar naar executables worden gezocht en bepaald de volgorde waarop dat gebeurd. Dingen die in /opt zijn geinstalleerd moeten op een of andere manier te bereiken zijn via een directory in PATH. /opt zit normaal gesproken niet in je PATH, maar misschien dat synology dat anders doet. Er zijn twee voor de hand liggende opties:
- synology heeft /opt/bin ook in $PATH gestopt.
- in (/usr(/local))/bin staan symlinks naar /opt/bin

Anyway,

echo $PATH

[Anoniem: 32925]

optware voegt /opt/bin:/opt/sbin: toe aan path, die zijn prefered

Anyway,

which ffmpeg

geeft aan welke je gebruikt

[trinite_t]

Als je een proces start op de achtergrond (met & aan het eind) dan kun je met $! het process id opvragen.

Wat je dus kunt doen:

code:

ffmpeg -params &
echo $! > pid_my_ffmpeg

dan staat in pid_my_ffmpeg het pid van je proces en is killen dus een eitje

[ Voor 5% gewijzigd door trinite_t op 29-09-2011 15:08 ]

[CAPSLOCK2000]

Ik he bnog een idee, er is een programmaatje genaamd 'start-stop-daemon' dat de mogelijkheid heeft om een proces te starten en het pid in een file te zetten. Het komt uit Debian en is deel van het dpkg-pakket maar misschien is het ook wel op andere systemen te gebruiken.

[sjongenelen]

trinite_t schreef op donderdag 29 september 2011 @ 14:34:
Als je een proces start op de achtergrond (met & aan het eind) dan kun je met $! het process id opvragen.

Wat je dus kunt doen:

code:

ffmpeg -params &
echo $! > pid_my_ffmpeg

dan staat in pid_my_ffmpeg het pid van je proces en is killen dus een eitje

haha dat is wat ik origineel zocht! afhankelijk van hoe goed nice bevalt is dit ook een optie dus

Anoniem: 32925 schreef op donderdag 29 september 2011 @ 14:26:
optware voegt /opt/bin:/opt/sbin: toe aan path, die zijn prefered

Anyway,

which ffmpeg

geeft aan welke je gebruikt

thx dat is handig!

[ Voor 21% gewijzigd door sjongenelen op 29-09-2011 15:59 ]

[Sir Isaac]

De PID van een programma opvragen doe ik normaal gesproken met pidof. Maar de optie van trinite_t lijkt me de beste, dat werkt ook als je een programma vaker hebt draaien.