=== j_ack [n=rudi@p508D8205.dip0.t-ipconnect.de] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === int0x0c [n=ben@161.253.47.133] has joined #upstart === int0x0c [n=ben@161.253.47.133] has joined #upstart === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === __keybuk [n=scott@wing-commander.netsplit.com] has joined #upstart [03:24] <__keybuk> complex-event-config is complex :-/ [03:25] :/ [03:25] <__keybuk> for example: [03:25] <__keybuk> on starting apache until stopped apache and starting dbus until stopped dbus [03:26] <__keybuk> do we stop apache from starting until dbus is starting? :p [03:27] hmmm [03:28] good point [03:28] that would be the only way to do it [03:29] as far as I can see [03:29] because otherwise if you let one of them start, it wouldn't satisfy the starting part [03:30] <__keybuk> so if dbus never starts, neither would apache? [03:30] yes [03:30] but that's a bit stupid [03:31] because it introduces an unnecessary dependency on dbus for apache [03:32] <__keybuk> indeed [03:53] Proper way would be to rewrite it into: [03:54] on starting apache and starting dbus [03:54] stop on stopped apache and stopped dbus [03:54] s/stopped/stopping/ [03:54] no [03:55] that's one of the points of complex-event-config, to have until :) [03:55] until is the same :P [03:55] <__keybuk> no it's not [03:55] <__keybuk> until pairs the events, where that doesn't [03:55] "pairs" [03:55] Explain what you mean by that :-) [03:56] <__keybuk> on foo until bar or frodo until bilbo [03:56] <__keybuk> foo happens. frodo happens [03:56] <__keybuk> both are TRUE [03:56] <__keybuk> bar happens, that only cancels the foo [03:56] <__keybuk> the right side is still true, so the job is still running [03:57] <__keybuk> on (foo or bar) until (frodo or bilbo) [03:57] <__keybuk> (or start on (foo or bar) ... stop on (frodo or bilbo)) [03:57] Shouldn't and do the same with "stop on x stopped and y stopped"? [03:57] <__keybuk> foo or bar happens, job is running [03:57] <__keybuk> err, [03:57] Or is that one-shot? [03:57] <__keybuk> foo or frodo happens, job is running [03:57] <__keybuk> bar happens, job would be stopped whichever of the two happened [03:58] <__keybuk> using a real example: [03:58] The "and" would group the events, but disregard ordering? [03:58] <__keybuk> on started gdm until stopping gdm and started kdm until stopping kdm [03:58] <__keybuk> gdm starts and kdm starts, job is running [03:58] <__keybuk> now let's say kdm stops, the job stops again because kdm is no longer running [03:59] <__keybuk> so far, that *is* equivalent to just using and [03:59] <__keybuk> except say kdm starts again [03:59] Ah, so it's like I thought. [03:59] "and" is one-shot. [03:59] <__keybuk> I don't understand "one-shot" [03:59] That means, the flag is read only once, because it isn't linked with the starting event. [04:00] <__keybuk> flag? [04:00] So, when stopped fires, the next started doesn't reset it. [04:00] <__keybuk> I still don't follow, sorry [04:00] <__keybuk> could you use an example to illustrate? [04:01] on x started and y started [04:01] stop on x stopping and y stopping [04:01] This would mean: [04:01] I start x and y [04:01] then stop y [04:01] then start y again [04:01] then stop x, the job is stopped. [04:01] <__keybuk> right [04:01] While with "until" that wouldn't happen. [04:02] <__keybuk> no, that'd happen with until too [04:02] Hmm. [04:02] <__keybuk> the point about "until" vs. "and" is that if you stop y then stop x, then start x again -- the job would be running if "and" is used, but not running if "until" is used [04:02] <__keybuk> compare: [04:02] <__keybuk> x started = FALSE, y started = FALSE [04:02] <__keybuk> x stopping = FALSE, y stopping = FALSE [04:02] <__keybuk> start x, x started = TRUE [04:02] Aha, now I get it. [04:02] <__keybuk> start y, y started = TRUE [04:03] <__keybuk> so the and is TRUE, so the job starts [04:03] <__keybuk> stop y, y stopping = TRUE [04:03] <__keybuk> the and is FALSE, so the job stops [04:03] Because the "x started" has already been set. [04:03] Yes. [04:03] <__keybuk> stop x, x stopping = TRUE [04:03] <__keybuk> the and is still FALSE, so the job is still stopped [04:03] <__keybuk> start x, x started = TRUE [04:03] <__keybuk> nothing has "reset" the y started = TRUE, so the and is still TRUE, so the job starts again [04:04] <__keybuk> the point about "until" is that it is a reset [04:04] While until resets the condition when the last one happens. So both would have to be started again, if both have been stopped. [04:04] <__keybuk> when the expression on the right side becomes TRUE, it explicitly resets the values on the left to FALSE [04:04] <__keybuk> right [04:06] <__keybuk> that's why we invented the complex thing [04:06] <__keybuk> we'd originally tried to just do it with adding and/or to start on/stop on [04:09] Hmm... [04:10] How would one do then failover services, which would be something like: [04:11] -start when any of foo, bar started [04:11] -stop when both of foo, bar stopped [04:12] (stopped means not running, not "stopped" event) [04:12] <__keybuk> err? [04:12] <__keybuk> that's what the stopped event means [04:12] You know, when you stop task, it sends that stopped event. [04:13] AStorm, that's what the state machine is for [04:13] it will be in the stopped state [04:13] But it won't send one, when it hasn't ever been ran. [04:13] Aha, great. [04:13] at least [04:13] I think so :) [04:13] <__keybuk> that's true, you don't have an event if it's never been run at least once [04:14] hmm [04:14] <__keybuk> we had "with" for that [04:14] <__keybuk> on not (with foo or with bar) [04:14] so if it hasn't been run then using stopped won't do anything? [04:14] <__keybuk> AlexExtreme: if you don't run a job, you don't get events for it ;p [04:14] <__keybuk> there's no "stopped foo" event just because it exists [04:14] It won't fire, if you mean that. [04:14] true :p [04:14] so you can't use 'on' based on something's state? [04:15] "on" won't reset. [04:15] or whatever ;) [04:16] <__keybuk> AlexExtreme: dunno yet, "on" is still being defined [04:16] with would work best. [04:16] k [04:16] What would happen then, if: [04:16] on not (with foo or with bar) [04:17] foo gets started [04:17] bar gets started [04:17] foo gets stopped? [04:17] Still running or not? [04:17] <__keybuk> with bar is true, so the on is false [04:17] <__keybuk> so not running [04:18] Hmm, not what I would like to :> [04:18] <__keybuk> use "and" then [04:18] <__keybuk> on not (with foo and with bar) [04:18] I figured that out... [04:18] <__keybuk> now running when either foo or bar or both are not running [04:18] But then, both foo and bar have to be started? [04:18] Ah, either? Really? [04:18] <__keybuk> yes, not ... and [04:19] This "and" is nonintuitive :D [04:19] <__keybuk> err, why? [04:19] <__keybuk> it's boolean [04:19] Actually... yep, it's alright. [04:19] We invert it, so we get a "nand" [04:19] <__keybuk> with doesn't combine well with until though [04:20] <__keybuk> which is why I haven't coded it yet [04:20] <__keybuk> and also acts strangelty [04:20] :| [04:23] What would: on (with foo or with bar) mean? [04:23] Either one of them, but stop if any of them is stopped? [04:24] Or stop if both are stopped? [04:24] <__keybuk> running when either one of them is running [04:24] <__keybuk> stopped only if both are stopped [04:24] with counts as stopped if it isn't running, right? [04:25] <__keybuk> right [04:25] <__keybuk> I'm increasingly thinking that complex-event-config is wrong [04:25] <__keybuk> it's cute, but doesn't fit in with existing behaviours [04:26] with sounds like a "need" dependency [04:26] almost exactly. [04:27] <__keybuk> what are the different deps? [04:27] Ok: use and need [04:28] There are 2 special orderings: before and after [04:28] (which map directly to "on") [04:29] Well, before doesn't actually. [04:29] It works like a "pre-start", but isn't tightly bound to the job. [04:30] after x == on x started [04:31] need x == with x [04:31] use x is special. Like a conditional after. [04:32] Wrong. Like a conditional need. [04:33] <__keybuk> use only applies if the job exists? [04:33] <__keybuk> whereas need always applies, so if the job doesn't exist, it isn't started? [04:33] Yes, if it's "added" to the "runlevel" [04:33] Doesn't map directly to events. [04:33] __keybuk, yes. [04:33] Or, when it's started, it pulls these as dependencies [04:34] So, it would be like: foo has "need bar" [04:34] if foo is started, bar is pulled in [04:34] if foo is stopped, bar is removed (or not, in case of Gentoo init - but that's a misfeature) [04:34] (should be removed when nothing else "needs" it) [04:35] when bar is stopped, foo is stopped too. === int0x0c [n=ben@161.253.47.141] has joined #upstart [04:36] It probably is possible to emulate using events alone, but isn't easy. [04:37] <__keybuk> how about with states? [04:37] <__keybuk> could you define them using states? [04:37] Hmm. there would be 4 conditions: [04:37] foo is started -> bar is started [04:38] foo is stopped -> nothing needs bar -> bar is stopped [04:38] foo is stopped -> something needs bar -> nop [04:38] foo is started -> bar is started -> bar is stopped -> everything needing bar is stopped [04:38] (including foo) [04:39] This would be hard to implement nicely with autoresurrecting services. [04:40] It would mean, when bar is restarted, restart everything needing it [04:41] <__keybuk> that works with the events at the moment [04:41] <__keybuk> since a job that's respawned emits stopping, starting, started [04:42] Yes. [04:42] But the hardest part is "something needs bar -> nop" [04:42] <__keybuk> why would it nop? [04:43] Because something else besides foo requires it. [04:43] so in this case, stopping foo shouldn't stop bar [04:43] while when only foo needs bar, bar should be stopped [04:43] Would require another event, let's say "lastneed" [04:44] or rather "noneed" [04:44] A simplel integer counter :P [04:44] bar noneed would be fired if it reaches zero [04:45] decreased when something needing bar is stopped [04:45] increased when something needing bar is started [04:48] Usually it's implemented using a stack and not events. [04:48] s/stack/array/ [05:03] __keybuk, in the replacement-initscripts branch, what is getmntent for? [05:04] <__keybuk> AlexExtreme: parsing /etc/fstab and /etc/mtab properly [05:04] <__keybuk> and not using grep or $IFS [05:05] <__keybuk> which are both broken if you want spaces in your mount points :p [05:05] ah [05:05] k :) [05:05] gonna hack them a bit [05:05] <__keybuk> wing-commander scott% sudo getmntent -f /dev/hda1 [05:05] <__keybuk> UUID=68210f07-2d06-416e-9db5-15db2b3e6b70 / ext3 defaults,errors=remount-ro 0 1 [05:05] <__keybuk> "where should /dev/hda1 be mounted?" ... note UUID lookup [05:06] <__keybuk> wing-commander scott% sudo getmntent -md / [05:06] <__keybuk> /dev/hda1 / ext3 rw,errors=remount-ro 0 0 [05:06] <__keybuk> "what's mounted on /" [05:06] <__keybuk> etc. [05:06] k [05:06] thanks [05:06] <_ion> You can also get the value of a specific field. [05:11] <__keybuk> I also intend to add an option to output FOO=... fields for use with udev [05:12] <__keybuk> so you could do SUBSYSTEM=="block", ACTION=="add", IMPORT{program}="/sbin/getmntent -f %k" [05:12] <__keybuk> then ENV{FSTAB_DIR}=="?*", RUN+="/sbin/initctl emit fstab-device-added %k" [05:12] <__keybuk> etc. [05:12] yes [05:13] <__keybuk> and then, more usefully [05:13] <__keybuk> SUBSYSTEM=="block", ACTION=="remove", ENV{FSTAB_DIR}=="?*", RUN+="/sbin/initctl emit fstab-device-removed %k" [05:13] <__keybuk> :p [05:13] <__keybuk> since you can't do a UUID lookup on a removed device [05:13] <_ion> Neat. === j_ack [n=rudi@p508DAAE9.dip0.t-ipconnect.de] has joined #upstart === __keybuk is wondering whether "until" is unnecessary [05:29] <__keybuk> start on starting foo [05:29] <__keybuk> stop on stopped foo [05:29] <__keybuk> is equivalent to [05:29] <__keybuk> on starting foo until stopped foo [05:30] hmm [05:30] all it does then is shortens things? [05:31] <__keybuk> complicates things [05:32] <__keybuk> thinking about whether it's better to make states a first-class thing, rather than something that can be defined with until [05:35] <__keybuk> so [05:36] <__keybuk> I tend to believe that if something is difficult to explain, or if something behaves in strange ways, then there's a problem with that something [05:36] <__keybuk> on/until is proving difficult to explain and behaving in strange ways [05:36] <__keybuk> which is starkly different from start on/stop on which behave simply [05:38] <__keybuk> vague thought [05:38] <__keybuk> start on EVENTEXPR [05:38] <__keybuk> stop on EVENTEXPR [05:38] <__keybuk> EVENTEXPR := EVENT | EVENT 'and' EVENT | EVENT 'or' EVENT | 'not' EVENTEXPR [05:39] hmm [05:39] <__keybuk> that's not that difficult [05:39] <__keybuk> start on foo or bar [05:39] <__keybuk> stop on foo and bar [05:39] that looks easy enough [05:40] <__keybuk> then add [05:41] <__keybuk> when STATEEXPR [05:41] <__keybuk> STATEEXPR := STATE | STATE 'and' STATE | STATE 'or' STATE | 'not' STATEEXPR [05:41] <__keybuk> where a STATE is just the name of a job [05:42] followed by an actual state such as started or stopped? [05:42] <__keybuk> no just the name of a job [05:42] <__keybuk> so just use job files instead of until [05:43] <__keybuk> not sure that solves the issue though [05:44] hmm [05:44] so STATE would be true if it is started? [05:44] and false if stopped? [05:45] <__keybuk> right [05:46] ok [05:46] <_ion> That syntax doesn't look bad. [05:46] yeah [05:51] <__keybuk> for the networking and filesystem case, you'd need: [05:52] <__keybuk> an /etc/event.d/networking file containing [05:52] <__keybuk> start on network-up [05:52] <__keybuk> stop on network-down [05:52] <__keybuk> an /etc/event.d/filesystem file containing [05:52] <__keybuk> start on filesystem-mounted [05:52] <__keybuk> stop on filesystem-unmounted [05:52] <__keybuk> and then any file would have [05:52] <__keybuk> when networking and filesystem [05:54] yes [05:55] <__keybuk> doesn't solve all of the problems though, I don't think [05:58] __keybuk, for the fsck, in order to get the device ID, use udevinfo --name= --query=env | grep ID_PATH [05:59] __keybuk, in the replacement-initscripts branch, what is getmntent for? [05:59] <__keybuk> AlexExtreme: parsing /etc/fstab and /etc/mtab properly [05:59] <__keybuk> and not using grep or $IFS [05:59] <__keybuk> which are both broken if you want spaces in your mount points :p [05:59] note the grep part ;) [06:01] <__keybuk> AStorm: udev is not a database :P === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart [06:22] __keybuk, udev knows the device ID. [06:22] getmntent doesn't know which device you're scanning :P [06:23] So, you would mount many things from one device at once. (unless watershed is powerful enough to avoid that) [06:23] /dev/sda1 and /dev/mapper/wtf may be on the same device. [06:23] Udev knows about these, so does sysfs [06:24] as far as I can tell getmntent also knows about that [06:24] Not the device part. [06:24] it uses libvolume_id from udev [06:25] So it doesn't tell you the data. :> [06:25] try it on some DM or RAID volume. [06:25] udevinfo also doesn't tell everything :/ [06:25] ls-ing /sys/block/.../slaves tells more [06:26] or ls-ing /sys/block/.../holders instead [06:26] But how to resolve /dev/mapper/wtf to dm-0? [06:27] Blah@me [06:27] dmsetup table... [06:27] (but that requires cut use) === AStorm [n=astralst@chello084010114027.chello.pl] has left #upstart ["Bye"] === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart [06:51] <__keybuk> AStorm: devmap_name [06:51] <__keybuk> (on Ubuntu) [06:52] Invoking the command as devmap_name is equivalent to [06:52] dmsetup info -c --noheadings -j major -m minor. [06:52] Blah, I'd have to know the minor and major number [06:52] <__keybuk> that's easy [06:54] <__keybuk> $MAJOR and $MINOR in the uevent === phsdv [n=paul@dyn-83-152-239-123.ppp.tiscali.fr] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart [08:20] Hi, I made an upstart script to fsck all file systems on a certrain blockdevice. It checks /etc/fstab with getmntent for filesystem on this block device [08:20] you can find the script here: http://upstart.pauldevries.homelinux.com/wp-content/uploads/fs-check.txt === AlexExtreme looks [08:22] It does not check the root partition, that will be dealt with seperately [08:22] yess [08:23] *yes [08:23] emit fs-checked $partition << shouldn't that be 'initctl emit fs-checked $partition' ? [08:23] yes, I made a link [08:23] ab [08:23] *ah [08:23] ok [08:24] In this way you only have one fsck per block device at a time. [08:24] and you can have multiple block devices checked in paralel [08:25] it probably does not handle yet names with spaces in there. But adding some "" should help out there [08:28] the script to fsck the rout partiton you can find here: http://upstart.pauldevries.homelinux.com/wp-content/uploads/fs-check-root.txt [08:28] I still need to get rid of the sleep statement though :( [08:29] ok [08:29] If I do not wait, I get errors... [08:29] i'll look at it later, i need to go now :) [08:29] ok [08:32] <_ion> It doesn't take LVM, RAID etc. into account. [08:33] <_ion> Or fsck returning a non-zero value. [08:33] no, not yet [08:33] but I do not have experience with LVM and RAID === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart === pornflake [n=garret@Ta56c.t.pppool.de] has joined #upstart