[02:56] <slangasek> pitti: so I've done some debugging of #537262, and I'm fairly convinced that this is simply a race condition resulting from sendsigs firing before the plymouth job has *started* on shutdown; there's little enough left in /etc/rc6.d on a stock system that this is very possible
[02:59] <slangasek> pitti: I think the right thing to do is, inside the 'for seq' loop, call initctl list again to check for any new jobs that have popped up; this is still not entirely race-free, but it is a fairly cheap fix (cheaper than waiting 10 seconds on shutdown for no reason) and should catch the vast majority of cases - what do you think?
[03:00] <slangasek> (even though we've stopped the crash reports now, we're still hanging around ~10s longer on shutdown than we need to because of this)
[06:54] <pitti> sbeattie: thanks
[06:55] <pitti> slangasek: that sounds plausible, at least much more than initctl having a bug of randomly not displaying jobs
[06:57] <pitti> slangasek: but what I don't understand is why plymouth would cause a 10 s hang then? doesn't it react to SIGTERM?
[06:57] <pitti> slangasek: i. e. if plymouth starts slightly late, then it wouldn't be on $OMITPIDS, and the killall5 would (try to) TERM it
[06:57] <pitti> which was the original effect described in the bug, I believe, that plymouth is killed prematurely
[07:00] <slangasek> pitti: it /can/ cause a 10s hang because it also races the invocation of killall5 - and indeed that's the case bug #537262 would correspond to, since if it had been caught by the first killall, the apport hook wouldn't have reported it
[07:01] <pitti> slangasek: hm, but wouldn't at least the third or fourth one kill it?
[07:03] <slangasek> pitti: the third and fourth ones use SIGCONT, which won't kill the processes :)
[07:03] <pitti> oh, indeed
[07:04] <pitti> right, of course; /me grabs some tea to wake up
[07:04] <pitti> yes, that makes perfect sense now
[16:54] <nigelb> can someone give me an ack for a UIFe for pitivi, bug 314885
[16:54] <nigelb> got blessings from translations and doc
[20:35] <kirkland> slangasek: is a new bash-completion file for a command line utility subject to FFe?
[20:47] <slangasek> kirkland: it's a feature, not a bugfix, so yes