[12:48] <AStorm> Hello.
[12:49] <AStorm> I heard that you're doing ubuntu init scripts too.
[12:49] <_ion> Welcome back. :-)
[12:49] <AStorm> I'm especially interested in the fsck - esp. not parallelising checks on things on the same physical drive.
[12:50] <AStorm> I have some ideas I've already implemented, but I'd like to hear yours.
[12:52] <AStorm> fsck itself isn't that good at checking multiple fses
[12:54] <AStorm> I wonder how does fsck check if the deviced are on the same physical device...
[12:59] <Md> major number?
[01:00] <_ion> That doesn't help much if you're e.g. comparing /dev/sda1 to /dev/volumegroup/foo which happens to be on software RAID-1, which happens to reside on /dev/sda2 and /dev/sdb2.
[01:02] <Keybuk> I didn't think fsck minded?
[01:02] <_ion> I assume fscking /dev/sda1 and /dev/sda2 simultaneously is *very* slow.
[01:03] <_ion> I don't see a reason for it not to work, but it's gotta be slow.
[01:09] <AStorm> Ok guys, did I miss something?
[01:09] <Keybuk> nope
[01:09] <AStorm> pfsck uses blkid_get_devname
[01:09] <AStorm> Which will fail with LVM or RAID.
[01:09] <AStorm> (fail to spot the use of the same device)
[01:10] <AStorm> My idea is to do some ls in /sys
[01:10] <AStorm> The dependency info is all exported in sysfs
[01:12] <Keybuk> what's the problem with checking the same device?
[01:12] <AStorm> seeking
[01:12] <AStorm> Means slowdown.
[01:13] <_ion> *Huge* slowdown, most likely.
[01:13] <AStorm> Not all that bad, because most fsck checks are small.
[01:13] <AStorm> I also wrote a tiny util to detect swap partitions.
[01:14] <AStorm> (4K on glibc)
[01:14] <AStorm> It could be useful when doing fsck totally automatically.
[01:16] <AStorm> (e.g. on HAL event when you hotplug your new shiny USB hard disc)
[01:17] <AStorm> Though some fsck options could probably fix it for us... if they are correctly implemented, that is
[01:17] <AStorm> not just checking the fstab
[01:19] <AStorm> Yes, it's broken. Will default to ext2.
[01:19] <AStorm> We could really use some FS detector.
[01:19] <Keybuk> AStorm: vol_id can do that
[01:20] <AStorm> How?
[01:20] <Keybuk> (detect swap partitions)
[01:20] <AStorm> Didn't work for me here...
[01:21] <AStorm> Ah, now it works. Stupid me.
[01:21] <AStorm> even the FS type (if known to the kernel)
[01:21] <AStorm> Ok, then it's no problem at all
[01:22] <AStorm> the devices will be discerned by sysfs data.
[01:23] <AStorm> ( reading /sys/block/*/* and /sys/block/*/*/slaves if present
[01:24] <AStorm> Probably there's some tool for that in sysfsutils too.
[01:24] <_ion> Has there been a lot of progress with the complex-event-config implementation?
[01:26] <AStorm> It works here :-)
[01:26] <Keybuk> _ion: I've written a parser
[01:26] <Keybuk> just need to rewrite that into the actual code and make it nice
[01:32] <AStorm> is "when x" isomorphic to "start on started x; stop on stopping x"?
[01:35] <Keybuk> there's no such thing as "when x" ?
[01:38] <AStorm> Bah.
[01:38] <AStorm> I meant "with x"
[01:39] <Keybuk> "with x" only exists in the complex-event-config
[01:40] <Keybuk> it's somewhat analogous to "starting x until stopped x", except that there's no serialisation of the two
[01:41] <AStorm> So it's more lax?
[01:41] <Keybuk> yes
[01:41] <AStorm> Nice still.
[01:42] <AStorm> I'm looking forward to complex-event-config full implementation.
[01:58] <Keybuk> me too
[10:37] <solemnwarning> Is upstart more stable then initng?
[02:18] <Keybuk> http://people.ubuntu.com/~scott/complex-event-config.patch
[02:18] <Keybuk> \o/
[02:33] <mbiebl> hehe, cool
[02:34] <mbiebl> Keybuk: Do you know, if the old sysv init sets the environment variables PREVLEVEL and RUNLEVEL on startup to N and S?
[02:34] <Keybuk> I have no idea
[02:34] <Keybuk> there's an open bug that the example job doesn't do that
[02:34] <Keybuk> I put the code in, and rc seemed to not work properly
[02:34] <Keybuk> so I'm not convinced
[02:36] <mbiebl> It's quite strange, the Debian udev scripts checks for the presence of these variables (and also splashy)
[02:36] <Keybuk> (this might just be a problem with /var/run/utmp, and /var/run not existing, of course)
[02:37] <mbiebl> But they are not set by /etc/init.d/rc
[02:37] <mbiebl> So, imho they must be set by sysv init.
[02:38] <mbiebl> I also find it strange, that bootmisc resets /var/run/utmp (to :) in S
[02:39] <Keybuk> yeah
[02:39] <Keybuk> sysvinit sets those itself
[02:39] <Keybuk> I think the bug is that we track the runlevel using /var/run/utmp as the authorative reference
[02:39] <mbiebl> Hard to N and S?
[02:40] <Keybuk> whereas sysvinit has an integer in memory that tracks it, and just uses utmp as an update
[02:40] <mbiebl> yeah, this is quite funny
[02:41] <mbiebl> if /var/run/utmp persists during reboot
[02:41] <mbiebl> You'd get 2 S from runlevel during S
[02:42] <Keybuk> pretty much the problem I had <g>
[02:42] <mbiebl> Do you know, if the behaviour of runlevel and PREVLEVEL/RUNLEVEL is specified somewhere?
[02:42] <Keybuk> I doubt it
[02:43] <Keybuk> I just used the sysvinit source as a reference for how they should behave
[02:43] <Keybuk> 0.3.5 is happily somewhat closer than 0.2.7 was
[02:43] <Keybuk> since "shutdown" now only generates runlevel change events
[02:45] <mbiebl> btw, I modified /etc/even.d/rcS for Debian to set PREVLEVEL/RUNLEVEL unconditionally to N/S
[02:46] <mbiebl> This is inconsistent to the output of runlevel at this  stage, but it seems to work fine.
[02:48] <Keybuk> that's a good idea :)
[03:03] <mbiebl> Yeah, it's then consistent to runlevel/previous defined in /etc/even.d/rc
[03:19] <AStorm> Keybuk, as to that init..
[03:19] <AStorm> Gentoo init depends on the fact that the RUNLEVEL is set to S or 1 on start.
[03:20] <AStorm> Had to fix that.
[03:23] <mbiebl> AStorm: What about PREVLEVEL?
[03:24] <mbiebl> Does the Gentoo init system make any assumptions about the value of this var?
[03:26] <AStorm> Not at all.
[03:27] <AStorm> (also, the runlevel names are special, like sysinit, single, nonetwork, default, reboot - not just numbers - but that's Gentoo-specific)
[03:27] <AStorm> the special sysinit runlevel is active only in S and there's explicit check for that
[03:27] <mbiebl> What's the output of runlevel during boot?
[03:28] <AStorm> Hmm?
[03:28] <mbiebl> Or when you have booted your system completely
[03:28] <AStorm> Completely.
[03:28] <AStorm> I'm running on upstart right now.
[03:28] <AStorm> (but totally using Gentoo scripts)
[03:28] <AStorm> (except the gettys - that also had to be hacked a bit)
[03:34] <AStorm> To be exact, the gettys were running too early
[03:35] <AStorm> making the init process look like crap
[03:35] <AStorm> Couldn't run them on stopped runlevel ...
[03:35] <AStorm> Because it didn't stop
[03:35] <AStorm> So I had to hack the last init script to emit that event.
[03:36] <AStorm> The always last script is /etc/init.d/local.start
[03:36] <AStorm> (due to after * clause in it)
[03:36] <AStorm> s/stopped runlevel/started runlevel/
[04:36] <Keybuk> runlevel is an event
[04:36] <Keybuk> not a job
[04:36] <Keybuk> events don't have a started or stopped :p
[04:37] <Keybuk> (unless you have an /etc/event.d/runlevel, of course)
[04:45] <_ion> Yay for complex-event-config.patch
[04:46] <Keybuk> it's still not "official" yet
[04:46] <Keybuk> it's only gdb-tested, and doesn't have test cases
[04:46] <Keybuk> and the code is messy at best
[04:46] <Keybuk> the implementation has some interesting side-effects too
[04:46] <Keybuk> e.g.
[04:47] <Keybuk> (foo and bar) until baz
[04:47] <Keybuk> foo happens, nothing
[04:47] <Keybuk> bar happens, it gets started
[04:47] <Keybuk> baz happens, it gets stopped
[04:47] <Keybuk> now, if foo or bar happen, it will be started again
[04:47] <Keybuk> since "foo and bar have happened" is satisfied
[04:47] <Keybuk> the until only "forgets" the AND combination
[04:48] <Keybuk> I actually quite like this behaviour, since the other intent can be expressed as:
[04:48] <Keybuk> foo until baz and bar until baz
[04:48] <Keybuk> (which requires foo and bar to both happen after baz, before it will be started again)
[04:50] <_ion> Well, that's exactly what i'd have expected to happen on (foo and bar) until baz
[04:50] <_ion> :-)
[04:51] <_ion> Agh, sorry. I misread your line as "if foo and bar happen, it will be started again"
[04:53] <_ion> Perhaps because there's "foo and bar" directly under the "foo or bar" ;-)
[04:56] <Keybuk> heh
[04:56] <Keybuk> after baz happens, it doesn't require foo and bar to both happen again
[04:56] <Keybuk> just one of them
[04:57] <AStorm> That's a bug.
[04:57] <Keybuk> is it though?
[04:57] <AStorm> It is. If you want "once" modifier, add it.
[04:57] <AStorm> from once foo and bar until baz
[04:57] <Keybuk> the "and" operator is TRUE if either expression has ever been TRUE
[04:58] <_ion> From the computer's point of view, that's the logical behavior. But from a human's point of view, it might be nicer if the code somehow reset the value of the (foo and bar) expression.
[04:58] <AStorm> hmm, or even
[04:58] <AStorm> from once foo and once bar until baz
[04:58] <_ion> ...when baz becomes TRUE
[04:58] <Keybuk> _ion: right, so the plan was that until would reset the tree on one side to FALSE when the other side went TRUE
[04:58] <Keybuk> and act as a flip-flop
[04:58] <AStorm> So, if both are satisfied _once_, they don't get reset
[04:58] <Keybuk> but that would have interesting interactions later with "with"
[04:58] <AStorm> But then... hmm.
[04:58] <AStorm> Weird.
[04:59] <AStorm> foo and once bar
[04:59] <AStorm> once foo and bar
[04:59] <AStorm> But both once degenerates to on.
[05:01] <AStorm> No, it doesn't :-)
[05:01] <AStorm> That'd be a nice extension.
[05:01] <AStorm> on once abc
[05:01] <AStorm> for a single-fire event
[05:02] <AStorm> (or even make on optional in this case)
[05:04] <AStorm> Like it?
[05:05] <Keybuk> not sure what the behaviour would be
[05:05] <AStorm> With once, or with those ands?
[05:05] <AStorm> The and should be like logic and
[05:05] <AStorm> And once should set a permanent flag
[05:06] <AStorm> It would be transitive too
[05:06] <AStorm> once (foo and bar) -> once foo and once bar
[05:10] <AStorm> similar with or...
[05:10] <Keybuk> I still don't get what "once" does?
[05:10] <AStorm> thought about adding xor?
[05:11] <AStorm> Keybuk, acts when the event is fired, but only once
[05:11] <Keybuk> so how is "once foo" different from "foo" /
[05:11] <Keybuk> once foo has been emitted, foo is always TRUE
[05:11] <AStorm> foo will fire multiple times
[05:11] <AStorm> Hmm.
[05:11] <Keybuk> sure, it can affect the tree multiple times
[05:11] <Keybuk> can you give me a use case for "once" ?
[05:12] <AStorm> Let me think...
[05:12] <AStorm> once startup-finished... mail me some info
[05:12] <AStorm> But then, you could create a one-time event
[05:12] <Keybuk> why not just make it a one-time event in the first place ? :p
[05:12] <AStorm> It's much better when you change and
[05:13] <AStorm> from bar and once foo until baz
[05:13] <Keybuk> change and?
[05:13] <AStorm> This means that if foo is fired once
[05:13] <AStorm> and baz is fired, we get launched
[05:14] <AStorm> unlike from bar and foo until baz
[05:14] <Keybuk> I still don't understand why this is useful, sorry
[05:14] <AStorm> which would mean that if both are fired...
[05:14] <AStorm> This means "foo got executed and finished, then on baz, do something"
[05:15] <Keybuk> I think you're confusing events and jobs?
[05:15] <AStorm> Probably.
[05:15] <AStorm> Due to JobEvents :P
[05:16] <Keybuk> job events went away
[05:16] <AStorm> Good.
[05:17] <AStorm> Well, then and works correctly it seems.
[05:17] <AStorm> (except that behaviour is not necessarily intuitive and has to be documented)
[05:18] <Keybuk> documentation is third on my TODO list :p
[05:18] <AStorm> :>
[05:18] <AStorm> Could lend you a hand there. Which format do you prefer?
[05:19] <Keybuk> docbook, I guess
[05:19] <AStorm> Could be asciidoc generated docbook?
[05:19] <Keybuk> what's that?
[05:19] <AStorm> asciidoc is a plaintext system
[05:20] <AStorm> http://www.methods.co.nz/asciidoc/
[05:21] <AlexExtreme> hmm
[05:21] <AlexExtreme> I could also help with docs
[05:23] <_ion> asciidoc looks quite nice.
[05:27] <AlexExtreme> hmm
[05:27] <AlexExtreme> the complex-event-config patch looks good
[05:28] <_ion> Ooo, nice. http://www.methods.co.nz/asciidoc/music-filter.html
[05:28] <_ion> Ooo, nice2. http://www.methods.co.nz/asciidoc/source-highlight-filter.html
[05:48] <AlexExtreme> Keybuk, how are the new jobs going? or haven't you started work on them?
[05:49] <Keybuk> slowly, but surely
[05:49] <AlexExtreme> cool
[05:50] <Keybuk> should be done today
[05:50] <_ion> Yay
[05:51] <AStorm> I have a question: How would one do normal logging to both console and system log?
[05:52] <AStorm> Use logger + echo?
[05:53] <Keybuk> or something like bootlogd or logd, etc.
[05:54] <AStorm> Yes, I was thinking about that logd
[05:54] <AStorm> How do you use that?
[05:55] <Keybuk> right now it's disabled
[05:55] <Keybuk> has a few bugs
[06:02] <AStorm> Ok, not a problem. For a while, I'll stick with plain echo.
[06:03] <AStorm> The hardest part is writing the network script
[06:03] <AlexExtreme> we talked about the possibility of integration with syslog-ng a while back
[06:03] <AStorm> the gentoo one is so universal, that it's quite slow :>
[06:03] <AStorm> (also, the network devices aren't parallelised)
[06:04] <_ion> astorm: It might be wise to start network interfaces based on events emitted by udev, too.
[06:04] <AStorm> Yep.
[06:04] <AStorm> Gentoo does that, but it has to wait for udev to settle :P
[06:04] <AlexExtreme> frugalware's networking script is quite simple, but it's not flexible in terms of bootup. everything is done by an external C program which uses profiles
[06:04] <AStorm> We don't have to.
[06:04] <AStorm> AlexExtreme, blah
[06:05] <AlexExtreme> why blah? :p
[06:05] <AStorm> I'd rather use a bunch of shell scripts :>
[06:05] <AStorm> and iproute2
[06:05] <AlexExtreme> :)
[06:05] <AStorm> and probably wireless-tools
[06:05] <Md> AStorm: only because currently daemons are started unconditionally when the interface is up. the correct way would be to start daemons when the interface is up, syslogd is running, /var is mounted, etc
[06:06] <AStorm> Md, yes, unfortunately.
[06:06] <AStorm> Gentoo init can be fixed, yes.
[06:06] <AStorm> But is it worth it? It is somewhat cruddy (e.g. /sbin/rc)
[06:07] <AStorm> _ion, I'm doing it right now, thank you
[06:07] <AlexExtreme> well
[06:07] <AStorm> :>
[06:07] <AlexExtreme> that would be hard
[06:07] <AlexExtreme> because
[06:07] <_ion> The result is probably a lot better than converting the gentoo script to upstart jobs automatically.
[06:08] <_ion> scripts
[06:08] <AlexExtreme> hmm wait
[06:08] <Keybuk> that's harder for Gentoo, because of their intricately interlinked deps
[06:08] <AStorm> No, it's the same as running the gentoo init.
[06:08] <AlexExtreme> no, forget i said anything
[06:08] <AlexExtreme> :)
[06:08] <Keybuk> they can't just remove one script
[06:08] <AStorm> Exactly. That's why they have to be wrapped.
[06:08] <Keybuk> because then all of its dependers wouldn't work
[06:08] <Keybuk> where as we can
[06:11] <AStorm> I simply wrap them in a wrapper script
[06:11] <AStorm> for upstart.
[06:11] <AStorm> And add a "runlevel" with a list of the deps.
[06:12] <AStorm> Still haven't got to modifying depscan.sh or rc-update to modify the file
[06:26] <AlexExtreme> hmm
[06:26] <AlexExtreme> that usplash in feisty atm is nice
[06:26] <AStorm> Hmm, what about checking a filesystem just before mounting? :>
[06:26] <AStorm> (except if a flag is given in the fstab, maybe...)
[06:27] <AStorm> upstart could be turned into an automounter too...
[06:27] <AStorm> (maybe not for network filesystems, for these there's autofs)
[06:29] <AStorm> Except that it wouldn't know who inserted the disc. So here, Unix user rights would have to be used.
[06:32] <AlexExtreme> hmm
[06:32] <AlexExtreme> does anyone know if kdump is implemented on feisty yet?
[07:35] <AStorm> Hmm, does initctl emit block until the event has been totally handled?
[07:36] <AStorm> and what about initctl start?
[08:06] <AStorm> ping, anyone?
[08:20] <int0x0c> AStorm, You have upstart running on Gentoo, right?
[08:26] <AStorm> int0x0c, in emulation currently
[08:26] <AStorm> writing the basic init and a proper init script emulation layer will take time
[08:27] <AStorm> I'm doing that currently
[08:27] <int0x0c> ahhh
[08:27] <AStorm> s/currently/right now/
[08:27] <int0x0c> heh
[08:27] <int0x0c> Have you seen Keybuk around recently?
[08:27] <int0x0c> I'm looking to port the init system fully to upstart
[08:27] <AStorm> [19:23:08]  * Keybuk has quit ("")
[08:28] <int0x0c> He's supposed to release a full upstart jobset soon
[08:28] <AStorm> I'm doing that too :-)
[08:28] <int0x0c> bah
[08:28] <AStorm> I'd appreciate the init scripts, but then, I'm porting it right now too.
[08:28] <int0x0c> ahhh, alright
[08:29] <int0x0c> I'm afraid I don't understand the init system well enough to port the base system scripts without some research
[08:30] <int0x0c> it would be great to get a full upstart init sequenceon gentoo
[08:31] <AStorm> It's actually quite simple.
[08:31] <AStorm> mount proc, dev, remount root ro
[08:31] <AStorm> start udev
[08:31] <AStorm> fsck root
[08:31] <AStorm> fsck other fses
[08:31] <AStorm> mount them
[08:31] <AStorm> that's the end of basic setup.
[08:31] <AStorm> The last step is starting gettys
[08:32] <AStorm> That's the basic skeleton. You probably want to add there some daemons, network setup, sound setup, such things.
[08:33] <AStorm> (forgot about remounting root rw :> )
[08:33] <AStorm> Also mount /dev/pts and /dev/usb optionally
[08:33] <AStorm> also, mounting sys
[08:35] <int0x0c> hmm
[08:35] <int0x0c> Have you implemented those as pure upstart jobs?
[08:35] <AStorm> Doing it right now.
[08:36] <AStorm> Actually, mostly done.
[08:36] <AStorm> Still working on improving the fsck
[08:36] <AStorm> Then, the init level/profile has to be launched. E.g. a script starting everything in some directory
[08:37] <AStorm> and stopping
[08:37] <AStorm> a runlevel simulation, that is.
[08:38] <AStorm> (or eINIT's mode, rather)
[08:40] <AStorm> At least until profiles are implemented.
[08:58] <AStorm> Well, the actual depscan.sh just launches a bunch of computation using awk
[08:58] <AStorm> I'd rewrite it in Python myself.
[08:58] <AStorm> (it's on Gentoo anyway)
[08:59] <AStorm> The emulation requires complex-event patch
[09:00] <AStorm> (otherwise it's impossible to link deps together)
[09:01] <AStorm> It's in awk, because the need system is too hard to implement in bash :>
[09:33] <int0x0c> Do you suppose you could post your base startup job somewhere?
[09:51] <_ion> Haha, i just now saw the picture Keybuk has at his launchpad page. :-)
[11:34] <AStorm> Hey guys...
[11:35] <AStorm> I wonder if this script is correct (with complex-events patch)
[11:36] <AStorm> http://wklej.org/id/8aba67fafb
[11:36] <AStorm> (check-fs does what you expect :-) )
[11:37] <AStorm> Maybe change the from line to
[11:37] <AStorm> start on started udev
[11:37] <AStorm> stop on stopped check-fs FS=/
[11:38] <AStorm> Hmm, or do I need something to listen on initctl events?
[11:39] <AStorm> Ah, no, I have to add sleep inf probably
[11:40] <AStorm> so that it's still running? (even with the fix for jobs w/o execs)
[11:49] <AStorm> I wonder...
[11:50] <AStorm> my test-event1 doesn't register as a job
[11:51] <AStorm> Ah, my bad. Braino
[11:53] <AStorm> Ok, got it :-)
[11:54] <AStorm> Is there a way to create a one-fire command that will block until the other event happens, or do I have to use that sleep inf hack?
[11:58] <AStorm> (which leaves nasty KILL messages around)
[11:58] <AStorm> mbiebl, oh, maybe you know.
[11:59] <mbiebl> AStorm: hi, what's up
[11:59] <AStorm> I wish to run a single-fire command, which should block until an event is fired
[11:59] <AStorm> sleep inf and using the dependencies leaves KILL messages.
[12:00] <AStorm> (looks yucky)
[12:01] <mbiebl> AStorm: could you explain a bit more detailed what you want to achieve
[12:02] <AStorm> I want to launch another event (which is an instance, so can't just wait on something)
[12:02] <AStorm> and then, block, until it finished
[12:02] <mbiebl> "launch an event" ?
[12:03] <AStorm> Actually, start a job
[12:03] <AStorm> But emitting an event would do the same
[12:03] <AStorm> Start command x, which returns
[12:03] <AStorm> and still wait until that one event
[12:06] <mbiebl> AStorm: Sorry, I think you lost me. I'd have to see the bigger picture to understand what you want to do.
[12:06] <AStorm> Launch 3 fsck in parallel
[12:06] <AStorm> and wait until they complete
[12:06] <AStorm> each fsck is a job.
[12:06] <AStorm> (because I would like to hook that up to udev events later)
[12:08] <mbiebl> Why do you have to wait, until all three of them have been completed?
[12:08] <_ion> "initctl emit foo" blocks automatically
[12:08] <AStorm> _ion, yep, but what will receive it? :>
[12:08] <AStorm> mbiebl, because then the mounting may happen
[12:08] <AStorm> (automounting that is)
[12:08] <_ion> /etc/event.d/test:
[12:08] <_ion> start on foo
[12:08] <_ion> exec sleep 5
[12:09] <AStorm> And I also want to use it in system startup sequence
[12:09] <_ion> % sudo initctl emit foo
[12:09] <AStorm> _ion, hmm, I have to pass parameters too
[12:09] <mbiebl> Well, I'd say, mount each partition separately when fsck has completed.
[12:10] <_ion> You probably should make the fsck job emit "filesystem-checked" and the mount job "start on filesystem-checked" or something like that.
[12:10] <mbiebl> I see no reason to way for / not being mounted because /usr is still checked.
[12:10] <mbiebl> s/way/wait/
[12:11] <AStorm> mbiebl, that's not the problem
[12:11] <AStorm> the problem is /usr/share mounted while /usr isn't
[12:11] <AStorm> :-)
[12:12] <mbiebl> Well, then the /usr/share mount job should "start on fsck-checked /usr"
[12:12] <AStorm> yeah right :>
[12:12] <AStorm> And I do know that from udev events :P
[12:13] <_ion> I'm not sure there should be separate mount jobs for separate partitions.
[12:13] <AStorm> _ion, there can, not a problem at all
[12:13] <AStorm> If I serialise mounting after the fsck
[12:13] <AStorm> _all_ of them
[12:14] <mbiebl> This is actually quite tricky.
[12:14] <mbiebl> You can't know in advance the partitioning scheme of a user.
[12:14] <AStorm> I can emit some events, right.
[12:14] <AStorm> yes, but can make educated guesses :P
[12:14] <mbiebl> So providing upstart mount jobs for each separate partition won't be possible.
[12:15] <mbiebl> You could, as _ion suggest, do the mounting in on single job.
[12:15] <_ion> Better make the mount intelligent: if MOUNTPOINT is /usr/share and there's a /usr entry in /etc/fstab, block until /usr is mounted.
[12:15] <_ion> Or something like that.
[12:15] <AStorm> Exactly.
[12:15] <AStorm> But not on the fstab check
[12:15] <AStorm> on mtab
[12:15] <AStorm> or rather, /proc/mounts
[12:16] <_ion> No, that doesn't contain /usr until /usr is mounted, right?
[12:16] <AStorm> fstab will be checked anyway, the mounts will be serialised separately by an external program
[12:16] <AStorm> I've temporarily solved the problem already, thank you.
[12:17] <AStorm> (I meant they will wait on each other, the scripts launched with an argument)
[12:19] <AStorm> Hmm, I could wait on the pids
[12:19] <_ion> % deps() { while read fstab_fs fstab_mountpoint rest; do case "$MOUNTPOINT" in "$fstab_mountpoint"*) echo "$fstab_mountpoint"; esac; done </etc/fstab }; MOUNTPOINT=/usr/share deps
[12:19] <_ion> If there's /usr in /etc/fstab, that should print it.
[12:20] <AStorm> More or less.
[12:20] <_ion> That's not a real implementation, it would print "/usr/loc" for /usr/local, but it demonstrates the idea.
[12:20] <AStorm> I know what I have to do...
[12:21] <AStorm> but the parsing will be done by an external program anyway.
[12:21] <AStorm> I just wonder, how to emit x events and wait on them all
[12:22] <AStorm> Well, wrong actually
[12:22] <_ion> for e in foo bar baz; do initctl emit "$e" & done; wait
[12:22] <mbiebl> AStorm: The basic question is, when can certain jobs start to run
[12:22] <AStorm> I can use complex-events and stop on (fsck / and fsck /usr and fsck /var and ... )
[12:22] <AStorm> But that will leave evil messages
[12:23] <AStorm> I will launch them using events, thank you.
[12:23] <AStorm> But what will wait w/o args do?
[12:23] <AStorm> mbiebl, that will be assured by another program and the deps :-)
[12:23] <_ion> wait for all children. To wait for only those initctls:
[12:24] <AStorm> Great then. Should've read the manpage better.
[12:24] <_ion> pids=; for e in foo bar baz; do initctl emit "$e" & pids="$pids $!"; done; wait $pids
[12:24] <_ion> (i didn't test that, though)
[12:24] <AStorm> Not a problem with "all children"
[12:25] <AStorm> The shell is running only these commands.
[12:27] <AStorm> Ok, so now the fsck problem is solved (thanks to emitting events)
[12:28] <AStorm> per-disk fsck is done too properly