[16:52] <dmart> Quick upstart question in Karmic:
[16:52] <dmart> I want to hook in a script to run on shutdown which runs as late as possible, but strictly before filesystems are unmounted.
[16:52] <dmart> Is is possible to do that with an upstart job, or do I need a SysV style link from rc[06].d?
[16:53] <sadmac> dmart: its likely possible, but its specific to Karmic's setup of upstart, and thus should be asked in an ubuntu-specific channel
[16:54] <dmart> OK
[16:55] <dmart> One related question is whether it's possible to put "before event" constraints in upstart jobs.  This would provide a framework for doing the kind of thing I'm talking about, but I couldn't see a way to do it.
[16:55] <Keybuk> not before event, no
[16:58] <dmart> Is there any plan to add such a thing?  This might make it easier to incorporate things like filesystem unmounting within the upstart framework.
[16:58] <Keybuk> sort-of
[16:59] <dmart> There might be a straightforward workaround that I'm not thinking of, of course
[16:59] <ion> The sysvinit script will die and become an Upstart job or part of one. Then you can nicely insert your own stuff based on the events emitted by said job.
[17:01] <dmart> My concern was that if you have some random tasks X, Y, Z which need to run on shutdown but before filesystem unmounting, then the unmount job must list them all: start on (stopped X and stopped Y and stopped Z)
[17:01] <Keybuk> no
[17:01] <Keybuk> X can be start on starting unmount
[17:01] <dmart> Are the jobs serialised... how do you ensure that the unmount job does not really run until X finishes?
[17:04] <Keybuk> they're serialised
[17:04] <Keybuk> jobs can block each other
[17:07] <dmart> Hmmm, OK.  Do you know if there's a good example somewhere I could look at?
[17:10] <Keybuk> man 7 starting
[17:14] <dmart> Keybuk: Ah, I seee.  Sorry for the newbie questions... I'm still finding my way around the upstart man pages.  Thanks!
[17:26] <dmart> Just to check my understanding, if I make a job start on (runlevel [09] and starting rc), will that have the desired effect of a job which runs on shutdown but before the final teardown done by rc?  Is start on starting rc RUNLEVEL=[06] equivalent?
[17:27] <dmart> (I mean [06], not [09])
[17:34] <Keybuk> actually
[17:34] <Keybuk> you can just do
[17:34] <Keybuk> the latter
[17:34] <Keybuk> start on starting rc RUNLEVEL=[06]
[17:34] <Keybuk> because /etc/init/rc.conf has export RUNLEVEL in it
[17:44] <dmart> Keybuk: OK, thanks for confirming.  I think I understand much better now :)
[19:17] <Berteun> hello someone here? :)
[19:17] <JanC> no  :P
[19:47] <Berteun> hi, i'm running into a problem which might be related to upstart
[19:48] <Berteun> i've just installed karmic 9.10 under a xen domu and now the system hangs, just as described here: https://bugs.launchpad.net/ubuntu/+bug/398214
[19:48] <Berteun> the bootlog is here: http://launchpadlibrarian.net/35544120/ubuntu910log-2.txt
[19:49] <sadmac> Berteun: I'd advise you to CC yourself on that bug then
[19:49] <Berteun> if i strip my /etc/init/ and remove quite a few scripts, it ends with init: event_finished: Finished startup event
[19:49] <Berteun> yeah okay
[19:49] <Berteun> and i suspect mountall is the culprit
[19:49] <sadmac> Berteun: you should probably comment on it too
[19:49] <Berteun> but that's only a vague guess
[19:50] <Berteun> so i'd like to explore that a bit more
[19:50] <Berteun> but i'm rather new to upstart
[19:50] <Berteun> so i'm more or less 'lost' 
[19:51] <sadmac> Berteun: if you want general information about upstart internals you're in the right place. As far as solving your issue, though, the launchpad bug is where you should be.
[19:51] <Berteun> okay
[19:52] <sadmac> There should probably be some document to link to about how upstart works. None has materialized though...
[19:53] <Berteun> yeah, i was looking around for that a bit, i found out about the --debug and --verbose parameters
[19:53] <sadmac> Berteun: you should look over all of the manpages that ship with upstart as a starting point. I believe there's one or two that cover the mechanics.
[19:53] <Berteun> okay
[19:54] <Berteun> is it also possible to start upstart if you boot with init=/bin/bash ?
[19:56] <sadmac> Berteun: you'd have to then "exec /sbin/init"
[20:00] <JanC> "man 5 init" gives some info about how upstart works
[20:00] <Berteun> but then it starts all its jobs again it thinks it can do (and it hangs) 
[20:01] <JanC> or at least enough to understand the upstart config
[21:06] <Berteun> it appears to be the mountall executable which causes the problems, is that applicable to this channel too?
[21:09] <sadmac> Berteun: technically not, but Keybuk wrote mountall, and afaik this is kind of the defacto place where it gets discussed still
[21:09] <Berteun> okay :)
[21:09] <sadmac> Keybuk: come forth and be pestered
[21:10] <Berteun> I just filed a bug and I'm not demanding it be solved right here and right now, just if some info is missing in the report: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/469985
[21:11] <sadmac> Berteun: you should point out in the original bug that it may be related
[21:11] <Berteun> I did that.
[21:11] <sadmac> cool
[21:59] <Berteun> i've got it
[21:59] <Berteun> probably
[22:01] <Keybuk> what did you got?
[22:02] <Berteun> it's an incompatiblity 
[22:02] <Berteun> mountall uses pipe2 which is unavailable in 2.6.26
[22:03] <Berteun> which is wrapped in NIH_ZERO( )
[22:03] <Berteun> hence it loops until it is succesful but it won't every be, because it is not there ;)
[22:03] <Keybuk> oh
[22:03] <Keybuk> right
[22:03] <Keybuk> mountall really needs .29 I think
[22:03] <Keybuk> probably even .31
[22:04] <Berteun> so basically ubuntu 9.10 is incompatible with dom0 lenny
[22:05] <Berteun> to make a long story short :)
[22:05] <ion> Wait... The host’s kernel version matters?
[22:06] <Berteun> well not really, but since ubuntu itself does not provide domU xen kernels the obvious choice is to use the debian lenny kernel.
[22:06] <Berteun> which most people do
[22:06] <Berteun> and then it does not work for an not enterily obvious reason
[22:07] <Berteun> debian uses 'xen old style' not the PvOps
[22:07] <JanC> ah, so I'm right it's a kernel feature mismatch somehow ☺
[22:08] <Berteun> Yeah, well, it was a bit of a risk of course to try to run an older kernel, but forward porting xen changes is not really my cup of tea ;)
[22:14] <Berteun> i'll make a note at the bug page, i'm not the only one it seems
[22:38] <dgtl> hi there
[23:29] <Keybuk> oh
[23:29] <Keybuk> I'm evil
[23:29] <Keybuk> ion: my --handover/--takeover stuff works :)
[23:29] <Keybuk> start plymouthd
[23:29] <Keybuk> plymouth --show-splash gives you the DRM/FB animation
[23:29] <Keybuk> when, when about to start X
[23:29] <Keybuk> plymouth --handover
[23:29] <Keybuk> and at the top of the gdm Init
[23:30] <Keybuk> plymouth --takeover
[23:30] <ion> Awesome. :-)
[23:30] <Keybuk> the splash pauses, X inherits the image
[23:30] <Keybuk> then begins animating again in X :)
[23:30] <ion> Would it be possible to skip --handover and have plymouth automatically pause at the last possible moment when it notices X has taken the framebuffer?
[23:32] <Keybuk> I don't think it works that way :)
[23:32] <Keybuk> it isn't using the framebuffer
[23:32] <Keybuk> it's using the DRM/DRI interface
[23:32] <Keybuk> so it's possible it'll lock X out
[23:35] <ion> Ah