[12:07] <seanius> hi guys, is there an authoritative guide for job file syntax somewhere?  most of the stuuff on the upstart wiki seems more "proposal-ish"
[12:08] <seanius> specifically wrt the version in hardy
[12:08] <Keybuk> man 5 init
[12:08] <Keybuk> oh, in hardy, no
[12:09] <seanius> yeah i've already heard through the grapevine that it might have changed since then
[12:10] <Keybuk> yes, and it will change again
[12:10] <seanius> should i just forget about trying then, and use something like rc.local?
[12:10]  * seanius would prefer inittab, but that's gone now it seems
[12:12] <seanius> or, is inittab supported in the -compat-sysv package but just not shipped by default?
[12:20] <seanius> ...it seems not (beyond default runlevel at least)
[12:21] <Keybuk> it's not supported, no
[12:21] <seanius> sorry for flooding teh channel btw :)
[12:22] <seanius> i have a service i'd like to run with supervision (i.e. "respawn") which should start after ssh/networking/postgres is brought up
[12:24] <seanius> is this possible to do in hardy's 0.3.9 upstart?
[12:29] <ion> Probably best to start it when rc2 has finished. But i don’t remember the precise syntax for 0.3.
[12:30] <ion> Something like
[12:30] <ion> start on EVENTSPEC
[12:30] <ion> service
[12:30] <ion> respawn
[12:30] <ion> exec yourservice
[12:31] <seanius> okay, i htink i can take that and what's sitting in event.d to try something, thanks!
[12:31] <ion> where EVENTSPEC is the correct string to match whatever happens when rc2 has finished.
[12:40] <seanius> ion: okay so that would be something like "start on started rc2"?
[12:41] <seanius> ...which is output from initctl events when i run "telinit 2"
[12:41] <ion> I take it there’s a /etc/event.d/rc2?
[12:42] <seanius> yeah
[12:42] <ion> Do you get a ‘stopped rc2’ when rc2 finishes?
[12:43] <seanius> i think i get that if i switch to runlevel 3
[12:43] <ion> You’ll probably want ‘start on stopped rc2’ or something like that.
[12:43] <ion> Hmh, not that, then...
[12:44] <seanius> yeah this is what i get http://paste.debian.net/48855/
[12:44] <seanius> this is switching from 2->3 and then back from 3->2
[12:45] <seanius> oh, it looks like it is saying "stopped rc2" last then isn't it...
[12:45] <ion> Did stopped rc2 happen before or just after switching to a new runlevel?
[12:46] <seanius> it looks like it's the last thing that happens when switching *to* that runlevel
[12:46] <seanius> so then i'd want "start on stopped rc2"
[12:46] <ion> Alright, that should work.
[12:47] <seanius> and if i want to stop it on reboot/shutdown would that be "stop on runlevel [06]" ?
[12:49] <ion> Look at what the tty* jobs do, that should work.
[12:49] <seanius> ah, just multiple stop stanzas
[12:50] <ion> The [016]-style pattern might only be supported in a newer version of Upstart.
[12:50] <seanius> there was a runlevel [!2] in the rc2 file at least
[12:51] <ion> Ok, it probably would work then.
[12:52] <seanius> allright, looks like we're up and running
[12:52] <seanius> thanks for the help
[13:23] <Keybuk> ion: I think I always used fnmatch() for that
[18:22] <akk> Hi! I updated karmic yesterday and now I can't boot with my self-compiled kernel -- mountall complains about /proc/filesystems, I think because I'm not using an initrd.
[18:22] <akk> I'm wondering if this is a permanent change, and if there's any workaround to boot without initrd?
[19:39] <sadmac> Keybuk: what are operations that one does on a device node that don't start with opening it and acting on the resulting descriptor?
[20:08] <JanC> akk: I've been looking at it a bit & I think a solution/workaround would be to edit the existing "mountall.conf" upstart script to add a 'pre-start' script that makes sure /proc (and maybe other requirements?) exist before mountall runs
[20:08] <JanC> but Keybuk or somebody else probably knows more about what the "right" solution would be  ;)
[20:11] <akk> JanC: Thanks for looking! Wouldn't I have to delay running mountall at all until it had mounted root readonly?
[20:12] <akk> Though d found that mountall 0.1.8 worked (two revs back).
[20:16] <JanC> akk: whatever requirements mountall has should go in the pre-start script (or in a separate upstart job on which mountall depends?)
[21:51] <chergert> can i have multiple "start on " lines in an upstart config? or do they need to be on one line?
[22:08] <mugwump> Anyone have any tricks for debugging early boot process with upstart?
[22:10] <Keybuk> sadmac: none that I can think of
[22:14] <sadmac_> Keybuk: well the mount command takes the path, but that can be gotten around...
[22:14] <sadmac_> Keybuk: a shocking proposal: axe device nodes. replace with connect(AF_DEVICE...)
[22:14] <Keybuk> sadmac_: then you can't alias them ;)
[22:14] <Keybuk> the network people (who have this) are trying to go the other way
[22:15] <Keybuk> akk: this is generally a channel for Upstream issues, try #ubuntu
[22:15] <Keybuk> akk: though because I'm nice, see bug 447947
[22:15] <sadmac_> Keybuk: sure you can. DNS can alias IP addresses, why can't some similar service alias major/minor pairs?
[22:15] <Keybuk> sadmac_: how so?
[22:16] <Keybuk> chergert: no.
[22:16] <Keybuk> mugwump: --debug on the kernel command-line is always fun
[22:16] <Keybuk> but you need quick reactions on the old scroll lock key ;)
[22:16] <Keybuk> (and a scroll lock key, bloody netbooks!)
[22:16] <mugwump> heh
[22:16] <mugwump> ctrl+s does the same thing on the console, no?
[22:16] <Keybuk> no...
[22:16] <Keybuk> :(
[22:17] <akk> Keybuk: Thanks!
[22:17] <sadmac_> Keybuk: basically you have a gethostbyname equivalent like getdevicebyname. you pass it a name, and it communicates to some service (probably a very re-invented udev) and returns a major/minor in a struct socaddr_device
[22:17] <mugwump> well, that's useful, thanks.  I actually ended up reinstalling because I couldn't figure out why the system wouldn't boot...
[22:18] <Keybuk> sadmac_: device filesystems are a more popular way of doing that <g>
[22:18] <sadmac_> Keybuk: but they suck.
[22:18] <mugwump> it would be nice to have details like that on the upstart man page
[22:18] <Keybuk> sadmac_: the only API I can think of that sucks more is, err, DNS
[22:19] <Keybuk> mugwump: it's a good point that init(8) doesn't document the options, could you file a bug about that?
[22:19] <sadmac_> Keybuk: if you tried out a web browser, and when you launched it instead of a website it gave you a blank window and the glade interface designer and said 'draw yourself a UI', and it did this every time you started it would you keep it?
[22:19] <mugwump> to which bugtracker?
[22:19] <mugwump> launchpad?
[22:19] <sadmac_> Keybuk: by that logic, where the fuck does the kernel get off giving userspace a some-assembly-required interface to hardware?
[22:20] <Keybuk> mugwump: http://launchpad.net/upstart/+reportbuf
[22:20] <Keybuk> mugwump: http://launchpad.net/upstart/+reportbug
[22:20]  * mugwump reports a buf
[22:20] <Keybuk> it might be +filebug ;)
[22:20] <mugwump> I'll find it :)
[22:26] <mugwump> Keybuk: https://bugs.launchpad.net/upstart/+bug/449883
[22:28] <mugwump> though it would be nice to have an option which starts a shell or something and requires you to prod it to make the next event fire
[22:28] <mugwump> quite often in that sort of situation I'll be doing diag checks between init scripts
[22:29] <Keybuk> yes, we should have that
[22:29] <Keybuk> in fact, my thought is that init will look at the kernel command-line options
[22:29] <Keybuk> and if any job exists with the names given, it will start that
[22:29] <mugwump> sure, why not
[22:29] <Keybuk> so you could have /etc/init/emergency.conf containing the code for a console root shell
[22:29] <mugwump> the decision to run as real init, it makes that based on the pid, right?
[22:29] <Keybuk> then if you stuck emergency on the kernel command-line then it would give you that
[22:30] <mugwump> that sounds pretty clean
[22:30] <Keybuk> that'd same code would make implementing things like "single" really easy too
[22:30] <Keybuk> (and most importantly let the mobile phone developers *not* have that <g>)
[22:30] <mugwump> do you use lxc for testing already?
[22:31] <mugwump> It should let you start a process that thinks it's pid 1
[22:31] <mugwump> and can't see any other processs
[22:31] <Keybuk> no, the test suite is pretty comprehensive though
[22:32] <mugwump> ah, good to know
[22:32] <mugwump> presumably you mock that somehow in the test suite
[22:32] <Keybuk> actually, very little requires that init be pid 1
[22:32] <Keybuk> the only reason, in fact, is because sysv let people call init to change the runlevel ;)
[22:32] <Keybuk> if you build upstart a certain way, you can cheerfully run it as any user
[22:33] <Keybuk> and use that one for testing
[22:33]  * Keybuk does that a lot
[22:33] <mugwump> reparenting I would have thought was pretty important
[22:33] <mugwump> or I guess not, maybe you only care about immediate children
[22:33] <Keybuk> not really, we don't get told about it
[22:33] <mugwump> do you get SIGCHLDs from them?
[22:34] <Keybuk> eventually yes
[22:34] <Keybuk> but there's no use for that, because we don't know what process it was ;)
[22:34] <Keybuk> pid 4131 died ... that's nice
[22:34] <mugwump> heh
[22:34] <Keybuk> kernel helpfully reaps info from /proc first
[22:34] <Keybuk> not that it would be reliable anyway
[22:35] <mugwump> or portable... any bsd users?  :)
[22:35] <Keybuk> I'm utterly uninterested in portability
[22:35] <Keybuk> Upstart is a Linux program
[22:39] <mugwump> fair enough, you won't find me complaining or submitting portability patches
[22:39] <Keybuk> I've suggested to the Debian/kFreeBSD nutters that they branch the code and rewrite it to be a BSD program ;)
[22:45] <sadmac_> ugh. I keep getting to places where I want to commit, but I don't want to because it would mean committing or digging out the piles of printfs that I want to still be in place for the next phase of implementation.
[23:13] <ion> keybuk: Btw, there’s the mnt->device "none" change sitting in my branch. Not very important, but anyway. :-)
[23:36] <ion> keybuk: The latest commit in the mountall repo breaks the code. I’m not quite sure what it’s attempting to do.
[23:37] <ion> Ah, now i get it. Yeah, just a missing ||
[23:39] <ion> keybuk: Fix in my branch.
[23:43] <Keybuk> oh, the fix is already in mine
[23:43] <ion> Alright
[23:44] <ion> uncommited and pushed; my branch still contains the (not very important) mnt->device "none" change.
[23:47] <Keybuk> the whuh?
[23:47] <Keybuk> oh that, I'll merge that in