| 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:06 |
|---|---|---|
| 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:07 |
| xnox | jderose: correct. | 12:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| jderose | okay, ubuntu-devel it is then | 12:25 |
| 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? | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| xnox | no. hud will be started again under upstart. | 13:08 |
| jderose | ah, /usr/lib/x86_64-linux-gnu/hud/dbus-activation-hack.sh, okay, now i understand :) | 13:11 |
| 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:19 |
| 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:24 |
| 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:26 |
| jderose | no, doesn't self shutdown... sure run for the entire desktop session. | 13:28 |
| 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:29 |
| 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:33 |
| xnox | upstart user sessions is optional, and on other desktop environments without upstart in user session it should still work as per above. | 13:34 |
| 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:40 |
| 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:41 |
| jderose | ie, why i'm not keen to have an instance of the service that isn't managed by upstart :) | 13:42 |
| 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:43 |
| 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:56 |
| 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:57 |
| 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 :) | 13:59 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| jderose | xnox: yeah, after logout the parent of couchdb is 1 | 17:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!