[12:32] My idea would be to distinguish between to different events: one being the root filesystem is availabe (basically everything besides /usr) [12:32] and the second being that the complete filesystem is mounted. [12:33] A small helper programm should figure out from parsing /etc/fstab which mount points have to be mounted for the first event [12:33] and then runs initctl emit root-fs-mounted [12:33] mbiebl, exactly [12:34] and when all filesystems are mounted emit the second event. [12:34] Yes, that's the plan and that's what I do. [12:34] I mount the systems in parallel too [12:34] (some time savings?) [12:35] You'd have to benchmark that, if it is really worth it. [12:35] That's why just after fsck is done iff the fs is not a subpartition, it is mounted [12:35] the fsck is bound to the mount [12:36] and the exact sequence is precalculated externally by a bash script [12:36] (could embed it and launch on runtime, possibly) [12:36] (but it probably requires something from /usr) [12:37] <_ion> deps() { grep -v '^[[:space:] ] *#' /etc/fstab | while read fs mp rest; do case "$MOUNTPOINT" in "${mp%/}"/*) echo "$mp"; esac; done }; MOUNTPOINT=/usr/share deps [12:37] <_ion> This should work, i think. [12:39] <_ion> (for all other mountpoints than / itself) [12:40] _ion: I'd reverse it: everything besides /usr [12:41] (Maybe /opt should be excluded too) [12:41] <_ion> Hmm. That function is supposed to give an answer to "i'm supposed to mount $MOUNTPOINT now; what mountpoints do i need to wait for first?" [12:43] Hm, but you couldn't use that expression in a "start on bla" stanza [12:44] Imo jobs should depend on either the root-fs being mount or everything (which includes network mounts) being mounted. [12:44] <_ion> This is what i was thinking: [12:45] <_ion> /etc/event.d/fsck: [12:45] Good, but actually I don't have to ask that [12:45] I know the sequence beforehand. [12:45] And yes, they do that (at least here) [12:45] <_ion> start on block-device-added blahblah [12:45] <_ion> script [12:45] They dep upon started mount-filesystems [12:45] <_ion> # do the magic [12:45] That's one script, yes. [12:45] But then, you don't want to mount it yet [12:46] <_ion> if that was successful: [12:46] You don't know what the user wants :> [12:46] <_ion> initctl emit filesystem-checked "$MOUNTPOINT" [12:46] <_ion> end script [12:46] <_ion> /etc/event.d/mount: [12:46] automounting has to have another table anyway [12:46] <_ion> start on filesystem-checked [12:46] <_ion> script [12:46] <_ion> deps() { ... } [12:46] <_ion> waitfor="$(deps)" [12:47] <_ion> # wait for stuff if they're not already mounted [12:47] <_ion> mount blahblah "$MOUNTPOINT" blahblah [12:47] <_ion> On success, emit filesystem-mounted -eMOUNTPOINT [12:47] <_ion> end script [12:47] :> [12:48] I actually do something like that, but in a script when setting the sequence. [12:48] It fscks them in this order too [12:48] <_ion> I don't think there should be a predefined order or sequence. [12:49] <_ion> Things should be done based on events, starting from when the devices appear. [12:50] The sequence is limited to a single disc. [12:50] (so as to not thrash and seek excessively) [12:50] Let me see... [12:50] Ok, doable, just a slight mod. I'll publish the scripts a bit later. [12:51] the thing is I launch "do-fsck thatdisc" [12:51] Actually, do-mount thatdisc [12:52] and this thing orders the mounts properly [12:52] <_ion> To avoid thrashing, you should have something like: [12:52] <_ion> /etc/event.d/fsck: [12:52] <_ion> ... [12:52] <_ion> script [12:52] <_ion> physdev=$(get the physical device name from somewhere) [12:52] fsck is just before mounting, so no problem [12:52] But then, the mount point ordering.. hmm [12:52] <_ion> watershed -i "fsck-$physdev" fsck "$DEVNAME" [12:53] I'd have to separate fsck from mounting. Will do that [12:53] <_ion> On success, initctl emit filesystem-checked -eMOUNTPOINT [12:53] <_ion> end script [12:53] So, I'll have to wait on all fsck's to finish [12:53] <_ion> And that's all you need to do, still no need to define a sequence. [12:53] which kind of destroys the event baseness [12:54] I don't have no watershed :P [12:54] s/don't// [12:54] but I have my own script checking the devices. [12:55] Ok, BBL [12:55] <_ion> wait [12:56] <_ion> The watershed source is in the diff.gz at https://launchpad.net/ubuntu/+source/udev/103-0ubuntu12 [12:56] I don't need it [12:56] there's sysfs, uh [12:57] and udevinfo [12:57] <_ion> Are you going to implement your own locking for the fscks to avoid thrashing? [12:57] No, I'll use event dependencies for it. [12:57] :> [12:58] <_ion> So you're going to have multiple fsck jobs, multiple mount jobs etc? [12:58] Exactly. Multiple instances of fsck job. [12:58] <_ion> I mean multiple fsck files in /etc/event.d [12:59] No. [12:59] Parameters work ok :P [01:00] <_ion> I'm not sure i understand how you're going to implement the thrashing-avoiding functionality then. [01:00] simple [01:00] launch "fsck-disc thedisc" [01:00] (on block-device-added probably, or maybe by hand by another script) [01:01] this will detect (or load from a file) what partitions are on that drive [01:01] <_ion> And that script implements the locking, no? [01:01] What locking? You don't need it, you scan the partitions in random order :> [01:01] <_ion> Well, let's say i run: [01:01] because, as you can see, no multiple partitions from the same drive can happen [01:02] (even counting dm or raid, because I'm a bit smarter when checking for "same device") [01:03] <_ion> Ah, i was indeed thinking that the fsck job would be triggered for each partition, but if it's only triggered for each physical device, it should work. True. [01:04] I wonder how to do that vgscan/mdscan thing with udev events [01:04] and esp. vgchange [01:05] These things will probably generate their own events, or none at all. [01:05] Well, could do them in another step altogether, that will waste a bit of time maybe... [01:06] Ehh, if I could just listen for some "stopped" events... [01:06] and I do mean listen. Not run something on them. [01:07] e.g. the physical group is on devices x, y and z [01:07] we want to wait until fscking on these devices ends and launch our own [01:08] and another is on devices a and b [01:08] wait on these too before fscking, but independent from x, y or z [01:14] <_ion> Personally i'd make something emit an event for each *partition* (also LVM partitions etc.) and make the fsck job start on that, figure out the physical device and implement locking based on that. [01:16] Hack, hack I say! [01:16] :> [01:16] The locking should be based on an event happening [01:16] (e.g. stopped fsck-disc somedrive) [01:17] But you can't just wait on an event in a script [01:18] initctl should be extended to support that [01:18] e.g. initctl wait stopped xyzzy [01:20] <_ion> I fail to see where the hack is. [01:20] I'd have to sleep on a file or something [01:20] or still sleep waiting for an event [01:21] <_ion> In order to do what? [01:21] How would the other partition jobs know that I'm not scanning the device? [01:21] Tell them on pipe? :P [01:21] also, race condition galore [01:22] <_ion> One instance: watershed -i fsck-physdev-sda fsck /dev/sda1 [01:22] <_ion> Another instance: watershed -i fsck-physdev-sda fsck /dev/volumegroup/foo [01:22] Yes, and? [01:22] and /dev/vg/x is on sda1 [01:22] :> [01:22] <_ion> Third instance: watershed -i fsck-physdev-sdb fsck /dev/sdb1 [01:22] <_ion> The first thing and the third thing are run simultaneously and the second one will block until the first is done. [01:22] How would the different watershed instances communicate? [01:23] Or are they smarter than that, somehow detecting that the device is in use? [01:23] or do they poll? [01:24] <_ion> They use /var/lib/watershed as a state directory, there are state files based on the ID (fsck-physdev-sda for example). [01:24] Or create a lock? (race condition possible...) [01:24] <_ion> I haven't looked at the implementation. [01:24] Aha, locks. [01:24] the process returns when it created the lock, right? [01:24] <_ion> I don't see how there could be a race condition. [01:24] <_ion> That's the point of locks: to avoid race conditions. :-) [01:24] I'd have to wait on it to create the lock, can't run x of them in parallel [01:25] Yes, but two things at the same time can try to create the lock :> [01:25] Both will fail, or just the one? [01:25] (that's fcntl for ya) [01:25] <_ion> One will succeed, one will block [01:25] <_ion> The point of watershed is that you run x of them in parallel and they handle the locking under the surface. [01:26] Good. Unless the kernel is broken, you say? [01:26] I can do such locking myself too :P [01:26] man flock [01:26] <_ion> Well, the kernel could be broken and poop turnips, but that's a kernel bug and not something one should work around in a totally unrelated program. [01:26] or course, this requires write access to some dir [01:27] <_ion> Naturally you could implement locking yourself, i just mentioned an already available tool. [01:27] preferably not /var, as that could get mounted before we remove the lock [01:31] some special state directory would be best [01:32] <_ion> watershed allows you to change the default with a command line parameter. [01:33] <_ion> For non-root users, it's ~/.watershed [01:33] Yes yes, that's nice, but the default should be good too. [01:33] I mean the root's default. [01:33] But then, why watershed when I can go with flock? :> [01:33] <_ion> /var/run/watershed is exactly the right default. :-) If it needs to be used before /var is mounted, it's a pretty special use case. [01:34] (and a bit of sysfs scanning) [01:34] <_ion> Whoops, /var/lib/watershed [01:35] <_ion> Argh, brainfart. It's /var/run/watershed of course. [01:35] The most convenient way would be to place a symlink on / device [01:42] Hmm. flock on a file will it be, then [01:42] Though I'd prefer waiting on an event. [01:42] (e.g. initctl wait) [01:52] <_ion> After actually looking at watershed's source (as it has no man pages ;-) ), that's not its purpose after all. [01:54] <_ion> Then there's dotlockfile(1) === j_ack_ [n=rudi@p508D8281.dip0.t-ipconnect.de] has joined #upstart === cables [n=cables@65-78-17-184.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com] has joined #upstart === Bourne [n=djzn@201.46.50.142] has joined #upstart [02:48] hi... how do I turn off scripts using upstart, just like the way Sysvinit command used to do? [02:49] <_ion> What do you mean by that? [02:49] <_ion> 'initctl stop jobname' stops an upstart job [02:49] <_ion> ('stop jobname' works as well)( [02:49] you know [02:49] in ubuntu breezy [02:49] you wanted to disable the scripts [02:49] just issued sysvinit [02:49] Breezy uses init, not Upstart [02:49] Edgy uses upstart [02:50] <_ion> cables: Yes and no. [02:50] and a in that window of sysinit, you just disable that [02:50] _ion, how's that? [02:50] how to do it with upstart [02:50] coz this is way slow [02:50] this is like XP... loading 89 default services [02:51] Bourne, http://en.wikipedia.org/wiki/Upstart [02:51] <_ion> Feisty will be the first Ubuntu release that actually contains upstart jobs (other than basic tty ones). And even that hasn't been implemented yet. In any Ubuntu release you're currently using, pretty much everything is still started by sysvrc scripts. [02:51] Bourne, read it. It's backwards compatible with sysvinit, so it will run your init scripts. [02:51] Bourne, _ion, I believe that Breezy actually just has the regular init, though... [02:52] Bourne, sorry, misunderstood your previous message to mean that you use breezy currently. [02:52] no [02:52] i used to [02:52] i just got back into the linux thing [02:53] and noticed that a lot of the thigns aren't there anymore [02:53] Bourne, Upstart is backwards compatible with sysvinit, you can configure it the same way... [02:53] switching to xubuntu desktop now [02:53] GNOME got way toooo slow [02:53] even on this fast computer === cables [n=cables@65-78-17-184.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com] has left #upstart ["Leaving"] [02:54] cables: i can't find a command here.... === cables [n=cables@65-78-17-184.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com] has joined #upstart [02:55] cables: to call upstart and disable services... is there one? [02:55] cables: i can't find a command here.... [02:55] cables: to call upstart and disable services... is there one? [02:55] <_ion> You don't have services started by upstart, other then the sysvrc scripts and some ttys. [02:56] how do I disable services... [02:56] that is all i want to know [02:56] just a command... [02:56] _ion, Isn't upstart just basically emulating sysvinit at this point? [02:57] <_ion> bourne: You're using xubuntu, right? Applications System Services [02:57] <_ion> cables: Yes. [02:57] ubuntu. yeah, i tried that already and disabled services.... [02:57] but I feel there's a whole bunch in the background [02:57] Bourne, if it's still running slow, then that's clearly not the solution... [02:57] i mean... [02:58] the Teardown stuff in ubuntu page [02:58] talks about 30 unusable scripts [02:58] their not listed in the Applications System Services [02:58] http://wiki.ubuntu.com/Teardown [03:01] well [03:01] I can replace upstart then [03:01] thats the only choice left [03:01] <_ion> Wtf? [03:01] as if I mark sysvinit to install, ubuntu takes out upstart in the software list [03:02] it does... if you go there and select sysvinit, it marks, but it reds out upstart, saying it's going to be removed [03:02] Bourne, you don't WANT to install sysvinit. [03:02] <_ion> Why the frell would you want to do that? [03:02] cables: what's the reason for that? [03:03] coz just the thought of upstart be loading a PCMCIA or Server stuff annoys me [03:03] Bourne, Upstart is just running sysvinit scripts now. [03:03] Bourne, so you just need to change those with a tool like "sysv-rc-conf" [03:03] oh yeah [03:04] tha command still works? [03:04] Upstart isn't actually being used as anything more than sysvinit in Edgy Eft [03:04] Bourne, if you install it... "sudo aptitude install sysv-rc-conf" [04:05] <_ion> Programmers: http://johan.kiviniemi.name/blag/2007/02/13/structure-and-interpretation-of-computer-programs/ === int0x0c [n=ben@128.164.102.43] has joined #upstart [05:21] _ion, great, thanks! [05:24] Smell of LISP... double plus then for functional programming. === Wimpog [n=Volodya@pool-141-154-153-110.wma.east.verizon.net] has joined #upstart === cables [n=cables@65-78-17-184.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com] has joined #upstart [05:27] Wimpog, have you asked your question? [05:27] preparing it now === cables [n=cables@65-78-17-184.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com] has left #upstart ["Leaving"] [05:27] GUYS, I need some help. I just installed Ubuntu server Edgy. AND THERE IS NOT /etc/inittab. GUYS from #ubuntu said it is by default like that. I want to know if there is some kind of equivalent of inittab in Edgy and if yes, where is it and what is it called? [05:28] <_ion> /etc/event.d [05:28] "/etc/event.d" is a directory [05:28] <_ion> Indeed. [05:29] I'm looking for some kind of equivalent of inittab [05:29] <_ion> Please elaborate on what you're trying to achieve. [05:30] say I want to change the boot level === ben_ [n=ben@161.253.17.231] has joined #upstart [05:30] normally you just edit /etc/inittab [05:33] <_ion> Ok, the compatibility jobs in /etc/event.d currently do parse /etc/inittab to find out the default runlevel. Create /etc/inittab and add the line id:N:initdefault: where N is the default runlevel you want. [05:35] Or, modify the default job instead :-) [05:36] hmm... what about adding a pipe to upstart? [05:36] <_ion> That too, but then you'd need to change the number in four places, i think. :-) [05:36] I like those Plan9-ish programs that only require echo :> [05:36] But then, initctl is adequate too. [05:36] There could be some proc-alike filesystem for the jobs :P [05:37] Maybe I'll write something with FUSE. Later. === Wimpog [n=Volodya@pool-141-154-153-110.wma.east.verizon.net] has left #upstart [] === ben_ [n=ben@161.253.46.176] has joined #upstart === ben_ [n=ben@161.253.47.141] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart [03:22] <_ion> Hi Keybuk [03:22] heyhey [03:22] <_ion> I moved the branch to my own server, since i keep having strange problems with launchpad.net (connections stalling until timeout), https://code.launchpad.net/~ion/+branch/libnih/watch-delayed [03:23] <_ion> Also: https://code.launchpad.net/~ion/+branch/upstart/watch-delayed [03:23] oh, cool, launchpad lets you "move" branches now? [03:24] <_ion> Oh, i'm not saying the fault is with launchpad. I've had such problems with many overseas servers. [03:24] <_ion> Well, i renamed the old one to watch-delayed-old and then created a new one that mirrors the branch at my server. :-) [03:24] ahh [03:24] ok [03:32] <_ion> Has there already been work to switch things from sysvrc to upstart 0.3.5 jobs? [03:32] <_ion> For feisty, that is. [03:33] yeah, need to start publishing that soon [03:33] I'm not sure it'll actually make it for feisty as default now [03:33] keep finding nasty bugs [03:33] <_ion> Cool [03:33] so I'm gonna just publish it and let everyone hack on it [03:33] what do you think is the best way to publish? bzr archive? [03:33] <_ion> Yeah, i'd like to test it, perhaps find bugs to fix. Yeah, bzr sounds good. [03:35] <_ion> Btw, is upstart going to go to the initramfs for feisty? [03:35] no === mbiebl [n=michael@e180113107.adsl.alicedsl.de] has joined #upstart [03:39] Keybuk: I guess you already noticed and I tell you nothing new: [03:39] The sulogin job file in feisty doesn't parse [03:39] oh? I didn't notice that [03:39] It still uses start instead pre-start [03:40] d'oh [03:42] Do I need the complex-event-spec patch for the [^x] syntax? [03:44] no [03:44] that's just using plain upstart [03:44] arguments to events are compared with fnmatch [03:45] ah, ok === ben_ [n=ben@161.253.47.141] has joined #upstart [04:04] https://code.launchpad.net/~keybuk/+branch/upstart/replacement-initscripts [04:05] <_ion> \o/ [04:05] it's nowhere near complete, yet === j_ack [n=rudi@p508D9A3F.dip0.t-ipconnect.de] has joined #upstart [04:09] Thanks Keybuk! [04:10] been trying to think how to do the "mount and unmount block device" type things [04:10] either they need to be two jobs [04:10] but there's also a certain elegance to them just being one job === j_ack [n=rudi@p508D9A3F.dip0.t-ipconnect.de] has joined #upstart [04:20] was thinking about adding a kind of syntax: [04:20] instance [04:20] start on block-device-added sd* [04:20] stop on block-device-removed $1 [04:21] ie. if the argument to "stop on" is $[0-9] * then it matches the equivalent argument in whatever event started it [04:22] <_ion> That would be nice. [04:23] <_ion> Will the block-device-added event have 'sda' or 'sda1' as the parameter? [04:23] depends which got added :p [04:23] it'd have sda for the block device, and then sda1 if there was a partition [04:25] <_ion> All right. Good. === mbiebl [n=michael@e180113107.adsl.alicedsl.de] has joined #upstart === ben_ [n=ben@161.253.47.141] has joined #upstart [04:30] <_ion> I was thinking something like this, is this sane at all? 0) The fsck job starts on block-device-added and emits filesystem-checked MOUNTPOINT=/foo/bar or whatever. 1) The mount job starts on filesystem-checked, and calculates a list of mountpoints it needs mounted *before* $MOUNTPOINT can be mounted (e.g. /foo/bar needs /foo if such exists in fstab). Then it blocks until the dependencies are mounted, and finally mounts $MOUNTPOINT. [04:30] <_ion> deps() { grep -v '^[[:space:] ] *#' /etc/fstab | while read fs mp rest; do case "$MOUNTPOINT" in "$mp"/*) echo "$mp"; esac; done }; MOUNTPOINT=/foo/bar deps [04:32] never grep fstab! [04:32] use getmntent() [04:32] <_ion> That was just a quick hack to demonstrate the concept. :-) [04:32] I hadn't considered that; (that /usr has to be mounted before /usr/share) [04:33] it can't really block, because that's racy [04:33] what if /usr gets mounted between it checking for it, and it blocking? [04:34] <_ion> Perhaps have something like: [04:34] <_ion> initctl wait filesystem-mounted /usr [04:34] racy [04:34] <_ion> True. :-\ [04:34] what happens if the filesystem is mounted while forking and execing initctl? [04:35] a better way might be to have the "mount from fstab" job run whenever a block device is added *or* another path is mounted [04:36] it'd check whether all necessary paths are mounted first [04:36] if they're not, it'd exit [04:36] <_ion> Ah, that sounds good. [04:36] if they are, it'd mount it -- and if it gets "already mounted", fail silently [04:38] <_ion> Hm, perhaps i should setup a virtual machine to play with replacement-initscripts in. [04:42] of course, that precludes using any $1 trick, since that'd be the path that was mounted above it [04:49] <_ion> Is there something like vmware-player, but free? [04:54] qemu? [05:00] _ion: If you want a nice gui you can also use virtualbox [05:00] http://www.virtualbox.org/ [05:00] They even provide packages for Dapper/Edgy [05:01] <_ion> Thanks [05:02] I use it myself. It's not as feature rich yet as vmware (it lacks the enterprise features) [05:03] but works great so far on my machine. === Keybuk just uses vmware [05:04] Do you have a license? [05:05] Or do you run vmware player [05:06] licence [05:06] ooh, nice [05:06] i'll try to play around with the new replacement scripts on frugalware today :) [05:08] AlexExtreme: note that they're only about quarter done; mounting of disks onwards is still todo === Keybuk has no particular problem with paying for useful software [05:08] yes [05:09] obviously I'd rather have the source, but for vmware we have access to the developers, so that's good too === AlexExtreme uses vmware [05:09] ... the trial version :P [05:10] I should probably switch from WS to Server sometime [05:15] I just use WS [05:15] I gotta admit that this WS 6 Beta is nice [05:16] not seen 6 [05:16] I've got a feisty install to play around with :) === ben_ [n=ben@161.253.46.176] has joined #upstart [05:25] hmm [05:26] Keybuk, i noticed you use mountpoint in the mount-kernel-filesystems job, isn't that a sysvinit util? [05:26] yes [05:27] hmm, shouldn't that be replaced somehow? or were you planning on doing that anyway? [05:28] why replace it? [05:28] the replacement code would be identical, no? [05:29] well, i don't mean rewrite it, just add a util that does the same to upstart, as it would be nice to get rid of the sysvutils (or whatever it's called) package sometime [05:31] why? [05:31] the tools in that package are perfectly fine they way they are, no? [05:31] hmm [05:32] that's a point [05:32] forget i said anything === Keybuk doesn't see a problem with upstart-compat-sysv depending on sysvutils [05:32] :p [05:32] now [05:32] (mountpoint is in initscripts, so obviously that one will have to move somewhere) [05:32] wait, damn [05:33] there goes my plans for working on upstart jobs [05:33] hmm? [05:33] damn school work :) [05:33] heh [05:33] oh well, bbl [05:33] mine today is "damn management stuff" [05:33] :( [06:06] http://codebrowse.launchpad.net/~keybuk/upstart/main/changes [06:06] sweet === ..[topic/#upstart:Keybuk] : Upstart 0.3.5 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | http://codebrowse.launchpad.net/~keybuk/upstart/main/changes | irc logs: http://people.ubuntu.com/~fabbione/irclogs | http://upstart.ubuntu.com/wiki/UpstartOnGentoo [06:42] sweet, inded [06:47] Keybuk: looks like the "description" and "files modified" sections should be merged [06:49] heh [06:49] only because I'm dilligent at changelogs, mostly [06:58] Keybuk: If I use the emit statement [06:59] How do I distinguish if I have two events or one event with a parameter [06:59] e.g. "emits foo bar" [07:01] emits just takes event names [07:02] it's just a documentation stanza, really [07:02] so other things can output dot for the relationships, etc. [07:02] also thinking of using it for "jobs that get told who's waiting for events they emit" kind of thing [07:03] And these events are triggered after entering the "started" state? [07:07] no [07:07] it's just documentation of what events that job is likely to emit on its own [07:07] e.g. [07:07] /etc/event.d/udev: [07:07] emits block-device-added block-device-removed [07:07] just says "udev might emit these events on its own" [07:08] ah, ok. [07:08] so one assumes that there's a udev rules.d file that does RUN+="/sbin/initctl emit block-device-added" in that example [07:08] it lets future UIs generate pretty graphs :p [07:10] What about "on". [07:10] I think it's ambiguous. [07:10] We have the "start on event" syntax, and simply the "on event" [07:10] heh [07:10] depends whether you're using complex-event-config.patch or not :p [07:11] Really? "start on" also works with 0.3.5 [07:12] right [07:12] "start on" and "stop on" are definitely staying [07:12] they take the name and arguments of an event that causes the job to be immediately started or stopped [07:12] multiple copies of those act as a kind of "or" [07:12] Yeah, my point is, we should get rid of the "on event" syntax. [07:12] well [07:13] so complex-event-config defines a new stanza that permits a much richer language to define the events [07:13] FOO started apache and filesystem-mounted until filesystem-unmounted and network-up until network-down [07:13] the "FOO" is not really pinned down yet [07:14] the experimental patch/branch steals "on" for that [07:14] with the intent that we'd rename it later [07:14] so on is already in the process of going away [07:14] it does happen that "FOO event" is exactly equivalent to "stop on event" [07:14] and that will always be the case [07:14] sadly [07:15] Hm, I'll have to reread the complex-event-config spec again, I guess. [07:16] It's a bit the same with exec and respawn [07:17] I'd prefer if respawn would simply be a flag [07:17] that's just syntactic sugar [07:17] (with an optional rate parameter) [07:17] respawn limit 5 [07:17] respawn interval 10 [07:18] uh [07:18] sorry [07:18] respawn limit 5 10 [07:18] [07:18] Well, the thing is, it makes it harder to generate nice GUIs. [07:18] yeah [07:18] respawn CMD nearly got dropped over the weekend [07:18] but it got a last-minute temporary parole [07:19] I'm edging closer to removing it though, since neither "service" or "daemon" accept commands [07:19] and service ~= respawn === AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart [08:08] Can't use dotlockfile [08:08] it's in mutt package, won't dep on it :P [08:08] flock it is. [08:09] (and checking /proc/mounts after taking the lock, in case we've waited and somebody mounted a filesystem earlier as a dependency) === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart [08:11] I'd still prefer listening on events. [08:12] (the locking stuff is mighty complex) === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart === phsdv [n=paul@dyn-88-122-32-158.ppp.tiscali.fr] has joined #upstart === j_ack [n=rudi@p508D9A3F.dip0.t-ipconnect.de] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart