[00:06] <karshan> hey
[00:06] <karshan> i'm looking for a way to get an upstart script running on shutdown, the only way I can seem to do it is with a "start on runlevel 0"
[00:06] <karshan> is there no analog event to startup in upstart ?
[00:09] <JanC> karshan: I thin kthat currently there is none
[00:09] <karshan> oh ok.. thanks. you know about any plans of removing the sysv legacy stuff like runlevels or is upstart gonna keep them
[00:10] <JanC> karshan: technically, the runlevel stuff isn't part of upstart
[00:10] <karshan> well i mean the runlevel events and the stuff in util/sysv.c etc.
[00:11] <JanC> some people (especially in the embedded space) don't use any of that
[00:12] <karshan> yeah I guess. I was just confused since all /sbin/shutdown does is set the runlevel to 0 and let out an event, it expects some sctript to run /sbin/halt on runlevel 0.
[00:12] <JanC> 'shutdown' is part of the sysv compatibility tools IIRC  ;)
[00:14] <karshan> ahh. yes ofcourse
[00:15] <karshan> I still think there should be a shutdown event (not runlevel 0) though, so when something like reboot is executed all jobs are stopped etc.
[00:16] <JanC> karshan: in general, upstart will just stop all jobs if you do that
[00:16] <karshan> JanC: well what about tasks that need to be carried out like unmounting the filesystems
[00:19] <JanC> karshan: you can use whatever event you want for that?
[00:21] <JanC> the thing with upstart is that it's very generic
[00:21] <karshan> but how do i get the event generated at shutdown
[00:21] <JanC> which is an advantage and a disadvantage
[00:22] <karshan> i.e. without putting an "inttctl emit shutdown" in the stop script of some random job
[00:23] <JanC> karshan: that's exactly what you want to do  ;)
[00:23] <JanC> actually, put it into the utility/script that starts shutdown
[00:24] <karshan> yeah that makes more sense
[00:24] <karshan> thats what I was saying though
[00:24] <JanC> and whatever name you give it is your choice
[00:24] <karshan> shutdown, or since thats sysv legacy, reboot should have something like that
[00:26] <karshan> i mean in reboot.c, there should be some code to emit a shutdown event, since it seems pretty useful, most systems would have scripts running on shutdown no ?
[00:27] <JanC> it might be useful to add an example reboot which does that
[00:27] <karshan> yeah
[00:28] <JanC> for those who want to set up a system without syv compatibility
[00:28] <JanC> sysv
[00:28] <JanC> (I'm not sure if one exists)
[00:29] <karshan> mm hmm.. you think its worth posting the code to the mailing list, see if it gets included maybe
[00:29] <JanC> Keybuk: ^^^
[00:29] <JanC> karshan: in any case, aking on the ML doesn't hurt  ;)
[00:29] <JanC> asking
[00:31] <JanC> currently most people seem to thing upstart is only upstart + sysv-compatibility as used in Ubuntu
[00:31] <karshan> yeah, so i've seen, it took me a while to find any scripts that had nothing to do with sysv compatibility
[00:32] <JanC> I expect Google's Chrome OS uses it differently
[00:32] <JanC> and the embedded users, but those might not always be public
[00:32] <JanC> or more difficult to find
[00:34] <karshan> yeah.. i'm building an lfs system, and i didnt want any sysv init stuff, so hopefully i'll have a nice set of upstart scripts legacy free by the end of it
[00:34] <JanC> karshan: in that case you can offer them to the project
[00:34] <karshan> yup :)
[00:34] <JanC> even if only to put them into an "examples" or "contrib" directory
[00:59] <Keybuk> hey was at the gym
[01:01] <JanC> Keybuk: karshan thinks it would be nice to include examples for a non-sysv-compatible system
[01:01] <Keybuk> JanC, karshan: right, the reason there's no non-SyS V shutdown event is because the people using Upstart without the SysV stuff are largely in the embedded space
[01:01] <Keybuk> and for them "poweroff -f" is pretty close
[01:02] <Keybuk> so it's not been a feature request someone's wanted enough to provide a patch
[12:12] <dcorbin_wk> How should (can I?) configure certain upstart services to be controllable by non-root users?
[15:39] <JanC> dcorbin_wk: configure sudo to allow them to execute the necessary commands?
[16:01] <dcorbin_wk> JanC: the commands are "start" and "stop", right?  can you make sudo only allow certain arguments?
[16:01] <JanC> yes, see sudoers(5)
[16:03] <JanC> there are all sorts of examples in it
[16:16] <dcorbin_wk> OK.  Thanks.
[18:24] <marrusl> Anyone know...  can you change the shell that upstart uses for scripts without changing the /bin/sh -> dash link?
[18:50] <SpamapS> marrusl: init/paths.h:#define SHELL "/bin/sh"
[18:50] <SpamapS> marrusl: tho Keybuk might know another way. ;)
[18:50] <marrusl> SpamapS, well THAT I'm not going to support.  :-)
[18:52] <Keybuk> hmm?
[18:54] <SpamapS> Keybuk: " < marrusl> Anyone know...  can you change the shell that upstart uses for scripts without changing the 
[18:54] <SpamapS>                  /bin/sh -> dash link?"
[18:54] <Keybuk> right
[18:54] <Keybuk> or
[18:54] <Keybuk> ./configure CPPFLAGS=-DSHELL=/bin/crush
[18:56] <marrusl> heh.  well thanks SpamapS, Keybuk.  good to know,  it's a weird request.  I don't think they'll care enough to want to roll their own.  :)
[18:59] <Keybuk> it's the kind of change that's best done at compile time
[19:01] <marrusl> Keybuk, and they are free to change the link if they'd really like to.  Not that i'm suggesting they do.
[19:06] <Keybuk> yeah, exactly
[19:06] <Keybuk> and really, Why?
[19:40] <marrusl> Keybuk, I'm curious, I didn't hear why yet.  I know they were working on a network startup issue (LP bug: 777193).  they probably added some debug statements that had a bashism in them.  probably wasn't anything more than that.
[20:28] <radix> I'm trying to get ubuntu working in a vserver... I've got it configured to some extent, where upstart is services properly when it comes up, but after that any start/restart/stop commands I run just block while polling on the connection to init
[20:28] <radix> is there something I should try to help figure out what's going wrong?
[21:52] <JanC> radix: there are some instructions about upstart + vserver on the vserver wiki IIRC
[21:52] <radix> JanC: yeah, and I followed them
[21:52] <radix> I'm not convinced that whoever wrote them got it fully working, or maybe just some software has changed since then
[21:52] <radix> they got me to the point that services were starting at boot, but I've always had this blocking problem
[21:52] <JanC> I have seen people in here who got it working with those instructions
[21:53]  * JanC has no experience with it though
[21:53] <Keybuk> if those commands block, you haven't got upstart working in a vserver
[21:53] <Keybuk> and are probably using some other daemon
[21:53] <reiddraper> if I have a process that I manage with upstart, and it forks on `reload`, will upstart keep track of it?
[21:53] <Keybuk> reiddraper: no
[21:53] <radix> it's definitely upstart, I've straced both init and the commands
[21:53] <radix> and seen them connecting on @/com/ubuntu/upstart
[21:53] <reiddraper> Keybuk: is there a workaround?
[21:54] <radix> could a misbehaving service specification possibly make one of those commands block? 
[21:56] <JanC> radix: in some cases
[23:52] <radix> 'strace -f restart cron': http://pastebin.ubuntu.com/603486/        'strace -f -p 1': http://pastebin.ubuntu.com/603487/
[23:52] <radix> could this perhaps offer some clue about my problem?
[23:54] <radix> it looks like the processes are at the very least communicating
[23:55] <radix> and netstat does tell me that process 1 is listening on @/com/ubuntu/upstart, so I assume that means it is actually upstart :)