[01:38] <fluter> hi
[01:38] <fluter> is there a tool to log and track all the events emited and handled by upstart and jobs?
[10:31] <xnox> fluter: please stay on irc
[10:31] <xnox> fluter: i've answered before, but you left.
[10:31] <xnox> fluter: there is upstart-monitor
[10:31] <xnox> and one can also use dbus-monitor
[10:32] <xnox> fluter: another option is to set $ initctl log-priority debug
[11:02] <fluter> xnox, sorry about that,
[11:03] <fluter> xnox, I'd like to see all event since system starts, 
[11:03] <fluter> initctl will be late I think
[11:03] <fluter> I will use upstart-monitor, thanks a lot
[11:04] <xnox> fluter: you can specify "--debug" on kernel command line, then it will be honer from the start of upstart
[11:04] <fluter> xnox, ah, that's great,
[11:04] <fluter> let me try it
[16:41] <jgornick> hey guys, if I start my application via start-stop-daemon, how can I run some script to stop the daemon when service my-service stop is called?
[16:42] <xnox> jgornick: did you look into "pre-stop" stanzas?
[16:42] <xnox> jgornick: in the cookboot
[16:42] <xnox> jgornick: in the cookbook
[16:44] <jgornick> xnox: Yes, but does that mean I should start-stop-daemon --start in the pre-start stanza and start-stop-daemon --stop in pre-stop stanza?
[16:44] <xnox> jgornick: no, why?
[16:44] <xnox> jgornick: pre-stop runs before killing the main pid.
[16:44] <xnox> jgornick: if you want to do clean up after your daemon is killed, use "post-stop"
[16:45] <xnox> (post-stop exec; or post-stop script/end script)
[16:45] <jgornick> xnox: I think you just shed some light on how Upstart works.
[16:45] <xnox> jgornick: it's all in the cookbook.
[16:45] <xnox> jgornick: read about the job life-cycle and what happens after what.
[16:45] <jgornick> xnox: Will do. Thank you!
[16:52] <jgornick> xnox: Is it good practice to use start-stop-dameon with Upstart?
[16:58] <detrout> I'm running upstart on debian testing/unstable and with kde and networkmanager. my laptop doesn't try to redetect network after changing locations while its sleeping.
[16:58] <detrout> any suggestions on where to look to diagnose that?
[17:01] <xnox> jgornick: usually no. but it's the last resort, if the daemon miss-behaves. (E.g. forks more than twice to reach the "main" process)
[17:01] <xnox> detrout: as far as I understand that's unrelated to upstart, just pure network-manager debugging.
[17:02] <xnox> detrout: and/or standard debian if-up / if-down scripts
[17:02] <detrout> ok
[17:02] <jgornick> xnox: Thanks for the insight. I've been able to get my application to start and stop gracefully now.
[17:02] <xnox> jgornick: no problem
[17:02] <detrout> i was wondering if upstart was missing the sleep/resume event and not triggering a reconnect
[17:03] <xnox> detrout: upstart drops an if.up script to generate events. but it doesn't configure networking at all.
[17:03] <detrout> where would the if.up script be?
[17:03] <xnox> detrout: no, upstart doesn't do anything on sleep/resume. pm-utils handles that.
[17:03] <detrout> ahh ok
[17:04] <xnox> detrout: if up & down scripts are all in /etc/network/. Again it's not upstart, but rather standard debian.
[17:04] <detrout> ok
[17:05] <detrout> and to make sure i'm understanding it... pm-utils is responsible for triggering on the ACPI sleep resume events, it calls into debian ifup/down, 
[17:07] <detrout> xnox: thank you for explaining.
[17:28] <xnox> detrout: pm-utils is responsible, unless you are running under logind session management, in that case it does take over some functionalities - e.g. activies triggered by power button, etc.
[17:30] <detrout> xnox: sid's network-manager pulls in libsystemd-logind
[17:31] <xnox> detrout: it's best for you to seek support on #debian / #debian-devel on OFTC.
[17:32] <detrout> Ok. thank you
[17:32] <xnox> detrout: i'm not that involved in debian network / boot stacks. despite being a debian developer =)
[17:32] <detrout> at least now I have a better idea why it worked when I was running systemd-sysv