[12:06] <jderose> So I have some experience with system jobs, and am experimenting with session jobs on 13.10. Am I correct that there currently are no dpkg hooks or other package magic for dealing with sessions jobs?
[12:07] <jderose> For example,  I was surprised that my session job wasn't shutdown when the package was removed (what I would expect with a system job).
[12:18] <xnox> jderose: correct.
[12:19] <xnox> jderose: upstart upstream doesn't define what the behaviour should be, distributions do.
[12:19] <jderose> xnox: is that something planned for the future? is there a current best practice i should follow for shutting down a session job when the package delivering the foo.conf file is removed?
[12:19] <xnox> jderose: so what should happen on package upgrade/downgrade/install/remove/purge/configure/deconfigure is something for a distribution to define.
[12:19] <xnox> jderose: Debian policy doesn't define it, nor do Ubuntu policies.
[12:20] <jderose> xnox: so in the case of ubuntu then... well there ever be similar behavior to how system jobs are currently handled?
[12:20] <xnox> jderose: you should not start, nor shutdown jobs on install/removal.
[12:20] <xnox> jderose: because e.g. a package is removed during upgrade, and the current instance should keep on running, otherwise you may cause data loss.
[12:21] <xnox> jderose: at the moment Ubuntu policy is following the general guidelines of Debian, where user running processes / data / any files in $HOME should not be modified.
[12:22] <xnox> jderose: i cannot speculate what may or may not happen, as no discussions about the Policy for the user sessions jobs has happened yet.
[12:22] <jderose> gotcha, thanks
[12:22] <xnox> jderose: if you want a better opinion / discussion about this, please start a discussion on ubuntu-devel-discuss or ubuntu-devel mailing lists.
[12:23] <jderose> xnox: which list is better for this sort of thing?
[12:23] <jderose> also, thanks for your help :)
[12:23] <xnox> jderose: ubuntu-devel-discuss, or if you have access (ubuntu membership) ubuntu-devel.
[12:25] <jderose> okay, ubuntu-devel it is then
[12:59] <jderose> xnox: so i notice that none of the session jobs in ubuntu 13.10 are using any 'start on dbus-activation org.foo.Bar'... is this feature not considered stable enough yet, or is it just a matter of things transitioning still?
[12:59] <xnox> jderose: as in to start job when a given bus name appears?
[13:00] <xnox> jderose: (the syntax you provide is not correct, and i am not sure specifically what you mean)
[13:00] <jderose> maybe i'm misunderstanding the features... i was thinking start when that bus name is requested
[13:00] <jderose> xnox: i was looking at the example here - http://upstart.ubuntu.com/cookbook/#run-a-job-when-a-user-logs-in
[13:01] <jderose> and also looking at the comment in /usr/share/upstart/sessions/hud.conf
[13:01] <xnox> jderose: 11.13 section does not work in Ubuntu 13.10, therefore please don't try to use it.
[13:02] <jderose> xnox: okay, thanks :)
[13:02] <xnox> jderose: it is on track to get fixed in Ubuntu 14.04
[13:02] <xnox> jderose: there are some other releases were it does work, can't remember off the top of my head at the moment.
[13:05] <jderose> xnox: hmm, so in 13.10, if you did `stop hud` and then requested something from com.canonical.hud over DBus, would you end up with a hud instance that upstart wasn't aware of, wasn't managing?
[13:08] <xnox> no. hud will be started again under upstart.
[13:11] <jderose> ah, /usr/lib/x86_64-linux-gnu/hud/dbus-activation-hack.sh, okay, now i understand :)
[13:19] <xnox> jderose: please don't follow that as best practices example. just wait until dbus-activation proper will be fixed in 14.04 and then all of these hacks will be gone.
[13:24] <jderose> xnox: so my DBus service currently uses an xdg autostart file to start after login, and then DBus activation to start it otherwise if it's not running for whatever reason. if i switch to upstart for my remaining 13.10 releases, what do you recommend i do? wouldn't i need to use an approach like the dbus-activation-hack.sh?
[13:26] <xnox> jderose: does your service ever self-shutdown? if not that simply add upstart job + xdg override in /usr/share/upstart/xdg/ (such that xdg-autostart is disabled under upstart)
[13:26] <xnox> and still keep the normal xdg autostart
[13:28] <jderose> no, doesn't self shutdown... sure run for the entire desktop session.
[13:29] <jderose> xnox: thanks for explaining /usr/share/upstart/xdg/... i was wondering why packages with session jobs were still including an xdg autostart .desktop file
[13:33] <jderose> xnox: one issue i see with the above: session jobs don't seem to automatically get started when the package is installed. so if a user installs my app and (without logging out or rebooting) opens one of the UI bits which needs the service, i'd get a instance of the service started through dbus activation, that upstart doesn't know about... right?
[13:33] <xnox> yes, and that's absolutely fine.
[13:34] <xnox> upstart user sessions is optional, and on other desktop environments without upstart in user session it should still work as per above.
[13:40] <jderose> so what i'm trying to fix with upstart is that in my very quirky use case, i need to be careful to cleanly shutdown the service otherwise i end up with a lingering couchdb process that lives on even *after* the user logs out (which will cause untold havoc should the user log back in)
[13:40] <jderose> currently i'm using org.gnome.SessionManager, but it's a bit fragile and doesn't work on the other ubuntu flavors
[13:41] <jderose> but upstart seems to do the trick, when it stops the service i don't have any lingering processes is the process group, even without using org.gnome.SessionManager
[13:42] <jderose> ie, why i'm not keen to have an instance of the service that isn't managed by upstart :)
[13:43] <jderose> xnox: anyway, thanks again for all the help! you seem to help me no matter what irc channel i'm asking questions in =D
[13:56] <xnox> jderose: add a second job, which "start on desktop-end" (or whatever the event is) which properly finds and kills _your_ coundbs and not anybody elses.
[13:57] <xnox> jderose: you should have started with that question.
[13:57] <xnox> jderose: "i have run away processes, how do i reliably kill them on logout?"
[13:57] <xnox> jderose: instead of making up a solution, and then asking how to implement your solution. =)
[13:59] <jderose> well, but assuming the service *is* managed by upstart, i don't have any issues with the run away process. the only missing thing is lack of dbus activation in upstart for 13.10.
[13:59] <jderose> but i see your point. either way, i learned a lot more about upstart :)
[17:11] <jderose> xnox: interesting, so even without a session job, without my org.gnome.SessionManager hack, on 13.10 i don't have any lingering couchdb processes after logout
[17:12] <jderose> whereas on 13.04 if i turn off my org.gnome.SessionManager hack, there is definitely a couchdb process still running after logout
[17:13] <xnox> jderose: i believe on 13.10, session init upstart does make a prctl call to make sure all processes are parented to session-init and do not get reparented to pid1.
[17:13] <jderose> so i guess the difference must be that the upstart managed user session is just much better at properly cleaning up after itself, even stuff that wasn't an explicit session job
[17:14] <xnox> jderose: can you look and compare the ps tree? and check whos is the parent of couchdb?
[17:14] <jderose> yeah, just a sec...
[17:26] <jderose> xnox: yeah, after logout the parent of couchdb is 1