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