[03:50] <crankharder> hey folks
[03:51] <crankharder> trying to track down a change that happened sometime between ubuntu 8.10 and 9.10
[03:51] <crankharder> on this 8.10 box I think all the upstart scripts are stored in /etc/event.d
[03:51] <crankharder> but the upstart docs say they should be in /etc/init -- but i dont see that on a 9.10 box
[13:42] <fsckroot> hello
[13:42] <fsckroot> could anybody direct me to some concise documentation about the boot process of upstart?
[13:43] <fsckroot> it seems to be sorely lacking everywhere I've looked
[13:43] <Keybuk> what would you like to know?
[13:44] <fsckroot> something like "this file is run first" --> which runs this one
[13:44] <fsckroot> etc. etc.
[13:44] <fsckroot> a tree or anything
[13:44] <Keybuk> the whole point of Upstart is that there is no documentation like that
[13:44] <fsckroot> just so I can get my head around the whole process
[13:44] <Keybuk> an Upstart boot process is designed so that the set of jobs run during boot can be completely flexible
[13:44] <fsckroot> I know
[13:44] <Keybuk> and can be run in different orders without problem
[13:45] <fsckroot> I gather that
[13:45] <fsckroot> kinda weird coming from an Arch / Slackware background
[13:45] <fsckroot> BSD init and such
[13:45] <Keybuk> right, it's quite difference
[13:57] <Keybuk> fsckroot: I guess the issue is that there's no real documentation on that
[13:57] <Keybuk> I have an idea that Upstart could log a boot sequence and give you output at the end saying what happened this time
[13:57] <Keybuk> "the startup event happened, so I started mountall"
[13:57] <Keybuk> "that service gave me a filesystem event, so I started udev"
[13:57] <Keybuk> etc.
[15:43] <JanC> Keybuk: such a log would certainly be useful for debugging boot/startup problems
[15:44] <Keybuk> yeah
[15:44] <Keybuk> I think I'd also like a kind of interactive boot
[15:44] <Keybuk> e.g. on a console
[15:44] <Keybuk> Received startup event, shall I start mountall [y/n] ?
[15:59] <sadmac2> Keybuk: if we do the enable/disable thing I talked about, we could tie it to that
[15:59] <Keybuk> precisely
[15:59] <sadmac2> Keybuk: "enabling service foo. is this ok?"
[15:59] <Keybuk> certainly related anyway
[16:15] <plundra> 5
[16:15] <plundra> Oops
[17:30] <Keybuk> plundra: that's exactly what I was going to say
[17:38] <plundra> In my defense; I was on my cellphone and intended to use Backspace. But Enter is next to it :P
[17:41] <plundra> So, anyone got any tips on redirecting stdout in a way that the respawn-functionality still works? 
[17:42] <plundra> This is on 0.3.9(? Or whatever, old anyway)
[17:43] <plundra> I added some hack last year, which logs start/stops and the output. 
[17:44] <Keybuk> no idea, respawn in 0.3.x was a bit hacky
[17:44] <plundra> I'll give you an idea of what I have, hold on. (Don't mock me!)
[17:46] <plundra> http://pastie.org/private/3urfpp4pdirtmnbnflkvaw
[17:47] <plundra> I hope I'll be able to upgrade to the next Ubuntu LTS some time this year, then I'll probably get some fancy new upstart :)
[17:47] <Keybuk> I don't know what you mean by "redirecting stdout in a way that the respawn-functionality still works"
[17:48] <plundra> Keybuk: It supervises the wrong pid.
[17:48] <plundra> So with the hack I pasted above, the loop-protection of respawn doesn't work.
[17:48] <Keybuk> does it matter which it does?
[17:48] <Keybuk> both will be in the same process group
[17:49] <Keybuk> and when one dies, the other should get SIGPIPE and exit no?
[17:49] <plundra> What matters is, if shit goes bad now, it'll loop and give send hundereds of mail.
[17:49] <Keybuk> maybe
[17:49] <Keybuk> not sure there's a proper way to do that with 0.5 either
[17:50] <sadmac2> *0.6 ?
[17:50] <Keybuk> right
[17:50] <plundra> Isn't there built in stuff for logging the output? I might be wrong though, havn't looked at the project at all for a while.
[17:50] <Keybuk> still relies on supervising a pid
[17:50] <Keybuk> no
[17:51] <plundra> "console" was the option I had in mind, but ok, no changes there?
[17:53] <Keybuk> none yet
[22:20] <mbiebl> hi Keybuk
[22:20] <mbiebl> could you apply this tiny patch for upstart, please: http://paste.debian.net/62034/
[23:23] <Keybuk> mbiebl: could you file that as a bug please?
[23:23] <Keybuk> (with the issue the patch fixes)
[23:24] <mbiebl> hm, well ok
[23:24] <mbiebl> I thought it was a no-brainer
[23:28] <Keybuk> I can't remember why that breaks
[23:28] <Keybuk> because it WFM
[23:34] <mbiebl> Keybuk: https://bugs.launchpad.net/upstart/+bug/530385
[23:35] <Keybuk> s/upstart/libnih/ *face palm*
[23:35] <Keybuk> oh, no, that is upstart
[23:35] <Keybuk> sorry
[23:36] <Keybuk> the weird thing is that I *don't* get that error
[23:37] <mbiebl> Keybuk: I have a lucid chroot
[23:37] <mbiebl> lemme try it there
[23:37] <Keybuk> works on karmic too
[23:40] <mbiebl> nope, fails exactly the same way for me
[23:43] <mbiebl> Keybuk: I used the 0.6.5 upstart and 1.0.1 libnih tarballs
[23:44] <Keybuk> koooky
[23:44] <Keybuk> works every time for me
[23:44] <mbiebl> Keybuk: could you try a clean chroot?
[23:44] <Keybuk> not sure how a chroot would change anything
[23:45] <Keybuk> the patch is clearly right
[23:45] <Keybuk> but just odd that it doesn't affect me
[23:45] <Keybuk> it looks like libtool is doing the dequoting
[23:45] <mbiebl> Keybuk: I guess it's a local modification on your system
[23:45] <Keybuk> don't see why
[23:45] <Keybuk> I don't *have* local modifications on my system
[23:45] <Keybuk> if I want to change something, I change the package and upload it <g>
[23:46] <mbiebl> This is weird indeed
[23:46] <mbiebl> as said, I can also perfectly reproduce it on the lucid chroot
[23:47] <Keybuk> oh
[23:47] <Keybuk> wait
[23:47] <Keybuk> your paste doesn't run through libtool
[23:47] <Keybuk> what configure args are you using?
[23:50] <mbiebl> ./configure --with-local-libnih=libnih-1.0.1
[23:55] <Keybuk> mbiebl: that's it?
[23:55] <Keybuk> how weird
[23:55] <Keybuk> wonder why it's not linking with libtool