=== pocek_ is now known as pocek
[14:10]  * ajb`` suspects what he's trying to do won't be possible with 0.3.9
=== ev1 is now known as ev
[14:20] <sadmac2> ajb``: I don't entirely understand the question
[14:52] <ajb``> sadmac2: I want to use upstarts respawn directive to ensure the daemon is restarted if it crashes.
[14:53] <ajb``> sadmac2: However if I want the daemon to pick up defaults from /etc/defaults/daemonname I need to use a script to start it
[14:54] <ajb``> That doesn't seem to work, at least on 0.3.9 respawn can only deal with a direct exec as otherwise upstart looses track of the daemons pid
[14:55] <ion> script
[14:55] <ion>   . /etc/defaults/foo
[14:55] <ion>   exec program args
[14:55] <ion> end script
[14:55] <ion> Make sure program doesn’t fork, that’s all.
[14:55] <ajb``> I tried that, but it didn't seem to work
[14:56]  * ajb`` tries again
[15:00] <ajb``> :-) it works now.. I must of had a subtly broken config before (probably experimenting with the daemon/fork directives)
[15:00] <ajb``> ion: thanks
[15:01] <ajb``> I'm guessing Hardy doesn't have any debhelper scripts for packaging things in /etc/event.d?
[15:01] <ion> It doesn’t.
[17:11] <ajb``> Is there any support for spawning processes under another uid? Or is that behaviour expected to be handled by the daemons themselves?
[17:12] <sadmac2> ajb``: there isn't yet. Upstart is poised to grow some very elaborate permissions stuff, so Scott didn't want to offer you a "wrong way of doing things."
[17:24] <ajb``> Hmm, I shall have to solve the problem another way for now then....
[17:27] <ajb``> I'm guessing post-start scripts have no gaurentee the daemon has run? Can the wait?
[17:29] <ajb``> s/the/the post-start script/
[17:35] <sadmac2> ajb``: if the daemon fails then the post-start shouldn't run
[17:36] <mbiebl>  ajb``: I guess you just use su -c for now
[17:39] <ajb``> sadmac2: I want to be sure the daemon has created it's socket before tweaking it's permissions
[17:39] <sadmac2> ajb``: that makes no sense from a security standpoint
[17:40] <sadmac2> ajb``: you want to make sure the daemon has an opportunity to do things before you worry about it doing bad things?
[17:42] <ajb``> sadmac2: least bad option, I can't do su -c ${DAEMON} as that confuses upstart's process tracking
[17:43] <ajb``> as forks will have happened
[17:43] <ajb``> So option 2, allow the daemon to run as root but tweak it's comms socket to be group writable to the the things that need to talk to it
[17:43] <sadmac2> ajb``: su is not /supposed/ to fork I think. haven't figured out why it does
[17:44] <sadmac2> ion: where is scott these days?
[17:44] <ajb``> sadmac2: doesn't su always imply a shell getting invoked at some point?
[17:47] <ajb``> http://pastebin.com/m74d9c60e
[17:48] <ion> sadmac: He had a vacation last week, but he’s been active in Launchpad this week. Dunno why he’s not here.
[17:49] <ajb``> Short of patching the daemon (rrdcached btw) to be a suid binary I think a chgrp/chmod of the socket is the easiest way for now
[17:50] <ajb``> When we move our product to the next LTS (assuming upstart has the new permission stuff) I can look at making it neater
[17:50] <ajb``> Anyway thanks for the help, have to head off now
[17:56] <mbiebl> ion, sadmac2: I think Scott's at LCA
[17:57] <mbiebl> http://www.lca2010.org.nz/programme/schedule/monday
[18:02] <ion> Ah
=== robbiew is now known as robbiew-afk
[19:18] <sadmac2> mbiebl: that'd do it
=== robbiew-afk is now known as robbiew