[08:20] <tobias-urdin> jamespage: if I could trouble you, when you have a second I would appreciate your feedback related to packaging in https://github.com/gnocchixyz/gnocchi/pull/1312
[08:20] -ubottu:#ubuntu-server- Pull 1312 in gnocchixyz/gnocchi "Use pbr rather than direct easy install" [Open]
[08:43] <jamespage> tobias-urdin: feedback provided but I really don't think that will be any problem
[08:49] <tobias-urdin> jamespage: thanks!
[15:37]  * bittin_working is installing some Debian and Ubuntu Server at work atm
[17:56] <Odd_Bloke> Hey folks, does anyone know a way that I could detect an `ffmpeg` process starting on my system and take an action on it?  (Specifically, I'm transcoding my entire library to take up less space, but I'd like to suspend that process if any _other_ ffmpeg process starts, because that activity is definitely higher-priority.)
[18:09] <JanC> Odd_Bloke: maybe starting the transcoding process with idle priority is enough?
[18:15] <Odd_Bloke> JanC: The process is nice'd, but I still see issues unfortunately.
[18:53] <sarnold> Odd_Bloke: maybe schedtool to set it into batch? my next idea is much less fun :) -- fiddle around with filtering execsnoop-bpfcc output to do what you want, or modify execsnoop.bt to issue the kill / freeze commands directly when needed
[18:53] <JanC> Odd_Bloke: idle has lower priority than what you can do with nice (see 'man chrt')
[18:54] <JanC> or schedtool indeed
[18:55] <JanC> I think schedtool isn't installed by default though?
[18:57] <sarnold> oh, hah
[19:00] <sarnold> .. I looked through the kernel sources for SCHED_IDLEPRIO, because that's what's mentioned in schedtool(8). Nothing. But there is a SCHED_IDLE, which is what's referenced in chrt(1)
[19:19] <JanC> BTW: even if you have a way to detect that two ffmpeg processes are running, it might not be simple to detect what ffmpeg process needs suspending
[19:20] <JanC> unless you look at its command line maybe
[19:24] <sarnold> /proc/pid/stat field starttime is the usual way to try to disambiguate multiple processes
[19:24] <JanC> but that still leaves a race condition :)
[19:25] <JanC> it might start transcoding the next file just after the other ffmpeg process starts
[19:31] <sarnold> mm true
[19:44] <znf> Assuming you are transcoding on the GPU, you can't "nice" that
[19:45] <JanC> that might be another issue indeed
[19:45] <JanC> znf: you can't "nice" it or you would have to do it differently?
[19:47] <znf> if you "nice" it, you only "nice" the CPU part
[19:47] <znf> but if you do it on the GPU... :)
[19:48] <JanC> I meant: is there a GPU task scheduler
[19:48] <JanC> or something like that; a way to set priorities for GPU tasks
[19:49] <znf> only for *some* CUDA loads, as far as I know
[19:52] <znf> basically: https://stackoverflow.com/a/6319289/2259612
[20:03] <Odd_Bloke> I'm encoding on the CPU, so not a problem for me.
[20:03] <znf> assuming he does those processes in a loop, he could write a flock and then check the pid of the script/loop 
[20:06] <Odd_Bloke> And, yeah, the to-be-stopped ffmpeg process is easily identifiable: it's running in a Docker container, so I can just `pkill --signal STOP ffmpeg` within that container.
[20:06] <sarnold> woot
[20:07] <Odd_Bloke> And yeah, the race condition is a possibility, but as the transcodes are taking 12+ hours each, I won't have too many opportunities to hit it. :p
[20:08] <Odd_Bloke> JanC: Aha, thanks, I'll try `chrt` out!
[20:09] <Odd_Bloke> (One wrinkle is that I'm not launching the ffmpeg processes myself, but a cron which just `chrt`s would be a much easier solution to this problem!)
[20:09] <sarnold> you could chrt the docker that launches it?
[20:10] <sarnold> scheduling classes are inherited across forks
[20:10] <JanC> by default, at least
[20:19] <Odd_Bloke> Hmm, well a quick test suggests that idle priority still interferes with a streaming transcode session, unfortunately.
[20:20] <sarnold> :( dang I liked that idea
[20:21] <Odd_Bloke> `chrt --idle -a -p 0 3734540` <-- after adding `-a` (so that the tasks actually doing the work were also changed) it did make a difference, if I wasn't operating with quite so little headroom for live transcodes it would probably have been sufficient
[20:21] <Odd_Bloke> But alas
[20:35] <JanC> it's probably easier to just run the transcode with chrt ("chrt -i 0 ffmpeg"), but if it doesn't work...