| === Keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart | ||
| AStorm | Hello. | 12:48 |
|---|---|---|
| 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:49 |
| AStorm | I have some ideas I've already implemented, but I'd like to hear yours. | 12:50 |
| AStorm | fsck itself isn't that good at checking multiple fses | 12:52 |
| AStorm | I wonder how does fsck check if the deviced are on the same physical device... | 12:54 |
| Md | major number? | 12:59 |
| _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:00 |
| Keybuk | I didn't think fsck minded? | 01:02 |
| _ion | I assume fscking /dev/sda1 and /dev/sda2 simultaneously is *very* slow. | 01:02 |
| _ion | I don't see a reason for it not to work, but it's gotta be slow. | 01:03 |
| === AstralSt [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
| === AstralSt is now known as AStorm | ||
| 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:09 |
| AStorm | My idea is to do some ls in /sys | 01:10 |
| AStorm | The dependency info is all exported in sysfs | 01:10 |
| Keybuk | what's the problem with checking the same device? | 01:12 |
| AStorm | seeking | 01:12 |
| AStorm | Means slowdown. | 01:12 |
| _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:13 |
| AStorm | (4K on glibc) | 01:14 |
| AStorm | It could be useful when doing fsck totally automatically. | 01:14 |
| AStorm | (e.g. on HAL event when you hotplug your new shiny USB hard disc) | 01:16 |
| AStorm | Though some fsck options could probably fix it for us... if they are correctly implemented, that is | 01:17 |
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| AStorm | not just checking the fstab | 01:17 |
| 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:19 |
| AStorm | How? | 01:20 |
| Keybuk | (detect swap partitions) | 01:20 |
| AStorm | Didn't work for me here... | 01:20 |
| 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:21 |
| AStorm | the devices will be discerned by sysfs data. | 01:22 |
| AStorm | ( reading /sys/block/*/* and /sys/block/*/*/slaves if present | 01:23 |
| 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:24 |
| 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:26 |
| AStorm | is "when x" isomorphic to "start on started x; stop on stopping x"? | 01:32 |
| Keybuk | there's no such thing as "when x" ? | 01:35 |
| AStorm | Bah. | 01:38 |
| AStorm | I meant "with x" | 01:38 |
| Keybuk | "with x" only exists in the complex-event-config | 01:39 |
| Keybuk | it's somewhat analogous to "starting x until stopped x", except that there's no serialisation of the two | 01:40 |
| AStorm | So it's more lax? | 01:41 |
| Keybuk | yes | 01:41 |
| AStorm | Nice still. | 01:41 |
| AStorm | I'm looking forward to complex-event-config full implementation. | 01:42 |
| Keybuk | me too | 01:58 |
| === _ion [i=johan@kiviniemi.name] has joined #upstart | ||
| === Amaranth_ [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === solemnwarning [n=solemnwa@cpc3-fare2-0-0-cust598.cos2.cable.ntl.com] has joined #Upstart | ||
| solemnwarning | Is upstart more stable then initng? | 10:37 |
| === pkt [n=knoppel@87.203.145.142] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === mbiebl [n=michael@e180122080.adsl.alicedsl.de] has joined #upstart | ||
| Keybuk | http://people.ubuntu.com/~scott/complex-event-config.patch | 02:18 |
| Keybuk | \o/ | 02:18 |
| mbiebl | hehe, cool | 02:33 |
| 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:34 |
| 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:36 |
| mbiebl | But they are not set by /etc/init.d/rc | 02:37 |
| mbiebl | So, imho they must be set by sysv init. | 02:37 |
| mbiebl | I also find it strange, that bootmisc resets /var/run/utmp (to :) in S | 02:38 |
| 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:39 |
| 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:40 |
| mbiebl | if /var/run/utmp persists during reboot | 02:41 |
| mbiebl | You'd get 2 S from runlevel during S | 02:41 |
| 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:42 |
| 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:43 |
| mbiebl | btw, I modified /etc/even.d/rcS for Debian to set PREVLEVEL/RUNLEVEL unconditionally to N/S | 02:45 |
| mbiebl | This is inconsistent to the output of runlevel at this stage, but it seems to work fine. | 02:46 |
| Keybuk | that's a good idea :) | 02:48 |
| mbiebl | Yeah, it's then consistent to runlevel/previous defined in /etc/even.d/rc | 03:03 |
| 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:19 |
| AStorm | Had to fix that. | 03:20 |
| mbiebl | AStorm: What about PREVLEVEL? | 03:23 |
| mbiebl | Does the Gentoo init system make any assumptions about the value of this var? | 03:24 |
| AStorm | Not at all. | 03:26 |
| 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:27 |
| 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:28 |
| AStorm | To be exact, the gettys were running too early | 03:34 |
| 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:35 |
| 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/ | 03: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:36 |
| Keybuk | (unless you have an /etc/event.d/runlevel, of course) | 04:37 |
| _ion | Yay for complex-event-config.patch | 04:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| _ion | Well, that's exactly what i'd have expected to happen on (foo and bar) until baz | 04:50 |
| _ion | :-) | 04:50 |
| _ion | Agh, sorry. I misread your line as "if foo and bar happen, it will be started again" | 04:51 |
| _ion | Perhaps because there's "foo and bar" directly under the "foo or bar" ;-) | 04:53 |
| 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:56 |
| 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:57 |
| _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:58 |
| AStorm | foo and once bar | 04:59 |
| AStorm | once foo and bar | 04:59 |
| AStorm | But both once degenerates to on. | 04:59 |
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| 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:01 |
| AStorm | (or even make on optional in this case) | 05:02 |
| AStorm | Like it? | 05:04 |
| 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:05 |
| AStorm | It would be transitive too | 05:06 |
| AStorm | once (foo and bar) -> once foo and once bar | 05:06 |
| AStorm | similar with or... | 05:10 |
| Keybuk | I still don't get what "once" does? | 05:10 |
| AStorm | thought about adding xor? | 05:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| Keybuk | I think you're confusing events and jobs? | 05:15 |
| AStorm | Probably. | 05:15 |
| AStorm | Due to JobEvents :P | 05:15 |
| Keybuk | job events went away | 05:16 |
| AStorm | Good. | 05:16 |
| AStorm | Well, then and works correctly it seems. | 05:17 |
| AStorm | (except that behaviour is not necessarily intuitive and has to be documented) | 05:17 |
| 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:18 |
| 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:19 |
| AStorm | http://www.methods.co.nz/asciidoc/ | 05:20 |
| AlexExtreme | hmm | 05:21 |
| AlexExtreme | I could also help with docs | 05:21 |
| _ion | asciidoc looks quite nice. | 05:23 |
| AlexExtreme | hmm | 05:27 |
| AlexExtreme | the complex-event-config patch looks good | 05:27 |
| _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:28 |
| === j_ack [n=rudi@p508DA3BD.dip0.t-ipconnect.de] has joined #upstart | ||
| === mbiebl [n=michael@e180122080.adsl.alicedsl.de] has joined #upstart | ||
| AlexExtreme | Keybuk, how are the new jobs going? or haven't you started work on them? | 05:48 |
| Keybuk | slowly, but surely | 05:49 |
| AlexExtreme | cool | 05:49 |
| Keybuk | should be done today | 05:50 |
| _ion | Yay | 05:50 |
| AStorm | I have a question: How would one do normal logging to both console and system log? | 05:51 |
| AStorm | Use logger + echo? | 05:52 |
| Keybuk | or something like bootlogd or logd, etc. | 05:53 |
| AStorm | Yes, I was thinking about that logd | 05:54 |
| AStorm | How do you use that? | 05:54 |
| Keybuk | right now it's disabled | 05:55 |
| Keybuk | has a few bugs | 05:55 |
| AStorm | Ok, not a problem. For a while, I'll stick with plain echo. | 06:02 |
| 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:03 |
| _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:04 |
| 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:05 |
| 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:06 |
| === _ion still recommends just starting /sbin/rc as the compatibility layer, and rewriting things gradually as upstart jobs. | ||
| 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:07 |
| _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:08 |
| 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:11 |
| AStorm | Still haven't got to modifying depscan.sh or rc-update to modify the file | 06:12 |
| 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:26 |
| AStorm | upstart could be turned into an automounter too... | 06:27 |
| AStorm | (maybe not for network filesystems, for these there's autofs) | 06:27 |
| AStorm | Except that it wouldn't know who inserted the disc. So here, Unix user rights would have to be used. | 06:29 |
| AlexExtreme | hmm | 06:32 |
| AlexExtreme | does anyone know if kdump is implemented on feisty yet? | 06:32 |
| AStorm | Hmm, does initctl emit block until the event has been totally handled? | 07:35 |
| AStorm | and what about initctl start? | 07:36 |
| AStorm | ping, anyone? | 08:06 |
| === int0x0c [n=ben@128.164.137.210] has joined #upstart | ||
| int0x0c | AStorm, You have upstart running on Gentoo, right? | 08:20 |
| === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart | ||
| AStorm | int0x0c, in emulation currently | 08:26 |
| AStorm | writing the basic init and a proper init script emulation layer will take time | 08:26 |
| 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:27 |
| 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:28 |
| int0x0c | I'm afraid I don't understand the init system well enough to port the base system scripts without some research | 08:29 |
| int0x0c | it would be great to get a full upstart init sequenceon gentoo | 08:30 |
| === int0x0c hates his dying spacebar | ||
| 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:31 |
| AStorm | That's the basic skeleton. You probably want to add there some daemons, network setup, sound setup, such things. | 08:32 |
| AStorm | (forgot about remounting root rw :> ) | 08:33 |
| AStorm | Also mount /dev/pts and /dev/usb optionally | 08:33 |
| AStorm | also, mounting sys | 08:33 |
| int0x0c | hmm | 08:35 |
| int0x0c | Have you implemented those as pure upstart jobs? | 08:35 |
| AStorm | Doing it right now. | 08:35 |
| 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:36 |
| AStorm | and stopping | 08:37 |
| AStorm | a runlevel simulation, that is. | 08:37 |
| AStorm | (or eINIT's mode, rather) | 08:38 |
| AStorm | At least until profiles are implemented. | 08:40 |
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| 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:58 |
| AStorm | The emulation requires complex-event patch | 08:59 |
| AStorm | (otherwise it's impossible to link deps together) | 09:00 |
| AStorm | It's in awk, because the need system is too hard to implement in bash :> | 09:01 |
| int0x0c | Do you suppose you could post your base startup job somewhere? | 09:33 |
| _ion | Haha, i just now saw the picture Keybuk has at his launchpad page. :-) | 09:51 |
| AStorm | Hey guys... | 11:34 |
| AStorm | I wonder if this script is correct (with complex-events patch) | 11:35 |
| AStorm | http://wklej.org/id/8aba67fafb | 11:36 |
| AStorm | (check-fs does what you expect :-) ) | 11:36 |
| AStorm | Maybe change the from line to | 11:37 |
| AStorm | start on started udev | 11:37 |
| AStorm | stop on stopped check-fs FS=/ | 11:37 |
| AStorm | Hmm, or do I need something to listen on initctl events? | 11:38 |
| AStorm | Ah, no, I have to add sleep inf probably | 11:39 |
| AStorm | so that it's still running? (even with the fix for jobs w/o execs) | 11:40 |
| AStorm | I wonder... | 11:49 |
| AStorm | my test-event1 doesn't register as a job | 11:50 |
| AStorm | Ah, my bad. Braino | 11:51 |
| AStorm | Ok, got it :-) | 11:53 |
| 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:54 |
| AStorm | (which leaves nasty KILL messages around) | 11:58 |
| === mbiebl [n=michael@e180096150.adsl.alicedsl.de] has joined #upstart | ||
| AStorm | mbiebl, oh, maybe you know. | 11:58 |
| 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. | 11:59 |
| AStorm | (looks yucky) | 12:00 |
| mbiebl | AStorm: could you explain a bit more detailed what you want to achieve | 12:01 |
| === int0x0c [n=ben@128.164.137.210] has joined #upstart | ||
| 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:02 |
| 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:03 |
| 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:06 |
| 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:08 |
| 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:09 |
| _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:10 |
| AStorm | mbiebl, that's not the problem | 12:11 |
| AStorm | the problem is /usr/share mounted while /usr isn't | 12:11 |
| AStorm | :-) | 12:11 |
| 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:12 |
| _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:13 |
| 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:14 |
| 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:15 |
| _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:16 |
| AStorm | (I meant they will wait on each other, the scripts launched with an argument) | 12:17 |
| 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:19 |
| 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:20 |
| AStorm | but the parsing will be done by an external program anyway. | 12:21 |
| === j_ack [n=rudi@p508DA3BD.dip0.t-ipconnect.de] has joined #upstart | ||
| AStorm | I just wonder, how to emit x events and wait on them all | 12:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| AStorm | The shell is running only these commands. | 12:25 |
| AStorm | Ok, so now the fsck problem is solved (thanks to emitting events) | 12:27 |
| AStorm | per-disk fsck is done too properly | 12:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!