=== jpabq is now known as jpabq_afk === jpabq_afk is now known as jpabq === jpabq is now known as jpabq_afk === django|away is now known as django [15:22] dekarl: thanks for committing that patch for the exec stuff [15:22] i'm glad to hear that sorts things out [15:22] i'm still a bit perplexed on why it's necessary though. isn't upstart supposed to track forks? [15:27] superm1, upstart only tracks forks if we tell it to (eg. 'expect fork') [15:27] but inside of that, IDK exactly why we're using exec instead of expect fork except that is what I was told :/ [15:28] oh i thought we had expect fork in the upstart job, but now that i look i see it's commented out [15:28] yea, IDK why that is [15:47] tgm4883: dekarl okay i think i'm following what's happening. upstart is tracking the PID of 'test' and the shell that sourced /etc/default/locale NOT the mythbackend PID [15:47] so when the kill signal is sent it gets sent to that shell not the backend PID [15:47] and then if you run it with exec it tracks the mythbackend PID at the end [15:47] mythbackend itself doesn't actually fork at all or anything [15:48] sorry if that's the same conclusion you came to, but if so it makes sense to me now :) [15:50] superm1: no worries.. I came to no conclusion at all, I just tested and pushed the fix that tgm4883 came up with :) [15:51] so the other remaining question is whether we bump the kill timeout up too [15:51] tgm4883 determined that the default between SIGTERM and SIGKILL signals is 5 seconds [15:53] I'm happy with using exec, thats what daemontools has in its run scripts, too. [15:53] If I understood correctly the 5 seconds are ok since the bug in shutdown was solved in parallel to us fixing the upstart job [15:55] i think that is the case too [15:59] searched for 5 minutes in irclog, commits and tickets didn't find the mention and giving up... only candidate being https://github.com/MythTV/mythtv/commit/0bb3bc2d9ca25528944429e84c21743db57b15a1 [16:13] superm1, sorry, yea I came to that conclusion previously but didn't explain all that [16:13] superm1, dekarl so while mythbackend is stopping in 2-3 seconds in our tests, should we be accounting for slower/complex systems? [16:14] superm1, dekarl I mean, if we set the timeout to 10 seconds, it's still going to only wait 2-3 seconds on most systems, but also give these other systems a little more time to shutdown before killing it [16:15] tgm4883: well looking through /etc/init there aren't many apps using a custom timeout [16:16] don't know that it would do any harm though [16:17] I don't think it would cause any harm. I'd think it would exist on precise (we should check) and thats the oldest we build for [16:17] superm1, I doubt many people would notice the 10 second timeout [16:18] true [16:19] superm1, I suppose the flip side of it is, what is the backend doing during shutdown that might be harmed by killing it early [16:19] superm1, that is probably the more important question [16:19] well maybe contacting mysql [16:19] but that might be killed early too [16:22] superm1, right, I'd just like a safe number to set as default [16:22] superm1, don't want to kill the backend if it's in the process of some mission critial stuff [16:23] OK well lets set it for 10 and see if we still get any complaints related to shutdown [16:23] it'll be better than what it is now [16:23] yea [16:23] sounds good [16:25] superm1, I'd have to see some other logs, but IIRC we're getting better messages in the mythbackend logs about shutting down (which is nice) [16:26] superm1, we could also turn logging way up, issue shutdown and see what it logs [16:26] all I get now is 4 lines [16:26] yeah if we have people complaining, that's definitely what we'll need to do [16:29] okay well i committed to master, 0.26, and 0.25. so we'll see in the next autobuilds what peoples says === jpabq_afk is now known as jpabq === Steve_Goodey is now known as Steve-Goodey