[03:24] <__keybuk> complex-event-config is complex :-/
[03:25] <AlexExtreme> :/
[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] <AlexExtreme> hmmm
[03:28] <AlexExtreme> good point
[03:28] <AlexExtreme> that would be the only way to do it
[03:29] <AlexExtreme> as far as I can see
[03:29] <AlexExtreme> 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] <AlexExtreme> yes
[03:30] <AlexExtreme> but that's a bit stupid
[03:31] <AlexExtreme> because it introduces an unnecessary dependency on dbus for apache
[03:32] <__keybuk> indeed
[03:53] <AStorm> Proper way would be to rewrite it into:
[03:54] <AStorm> on starting apache and starting dbus
[03:54] <AStorm> stop on stopped apache and stopped dbus
[03:54] <AStorm> s/stopped/stopping/
[03:54] <AlexExtreme> no
[03:55] <AlexExtreme> that's one of the points of complex-event-config, to have until :)
[03:55] <AStorm> 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] <AStorm> "pairs"
[03:55] <AStorm> 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] <AStorm> 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] <AStorm> 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] <AStorm> 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] <AStorm> Ah, so it's like I thought.
[03:59] <AStorm> "and" is one-shot.
[03:59] <__keybuk> I don't understand "one-shot"
[03:59] <AStorm> That means, the flag is read only once, because it isn't linked with the starting event.
[04:00] <__keybuk> flag?
[04:00] <AStorm> 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] <AStorm> on x started and y started
[04:01] <AStorm> stop on x stopping and y stopping
[04:01] <AStorm> This would mean:
[04:01] <AStorm> I start x and y
[04:01] <AStorm> then stop y
[04:01] <AStorm> then start y again
[04:01] <AStorm> then stop x, the job is stopped.
[04:01] <__keybuk> right
[04:01] <AStorm> While with "until" that wouldn't happen.
[04:02] <__keybuk> no, that'd happen with until too
[04:02] <AStorm> 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] <AStorm> 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] <AStorm> Because the "x started" has already been set.
[04:03] <AStorm> 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] <AStorm> 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] <AStorm> Hmm...
[04:10] <AStorm> How would one do then failover services, which would be something like:
[04:11] <AStorm> -start when any of foo, bar started
[04:11] <AStorm> -stop when both of foo, bar stopped
[04:12] <AStorm> (stopped means not running, not "stopped" event)
[04:12] <__keybuk> err?
[04:12] <__keybuk> that's what the stopped event means
[04:12] <AStorm> You know, when you stop task, it sends that stopped event.
[04:13] <AlexExtreme> AStorm, that's what the state machine is for
[04:13] <AlexExtreme> it will be in the stopped state
[04:13] <AStorm> But it won't send one, when it hasn't ever been ran.
[04:13] <AStorm> Aha, great.
[04:13] <AlexExtreme> at least
[04:13] <AlexExtreme> 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] <AlexExtreme> hmm
[04:14] <__keybuk> we had "with" for that
[04:14] <__keybuk> on not (with foo or with bar)
[04:14] <AlexExtreme> 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] <AStorm> It won't fire, if you mean that.
[04:14] <AlexExtreme> true :p
[04:14] <AlexExtreme> so you can't use 'on' based on something's state?
[04:15] <AStorm> "on" won't reset.
[04:15] <AlexExtreme> or whatever ;)
[04:16] <__keybuk> AlexExtreme: dunno yet, "on" is still being defined
[04:16] <AStorm> with would work best.
[04:16] <AlexExtreme> k
[04:16] <AStorm> What would happen then, if:
[04:16] <AStorm> on not (with foo or with bar)
[04:17] <AStorm> foo gets started
[04:17] <AStorm> bar gets started
[04:17] <AStorm> foo gets stopped?
[04:17] <AStorm> Still running or not?
[04:17] <__keybuk> with bar is true, so the on is false
[04:17] <__keybuk> so not running
[04:18] <AStorm> 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] <AStorm> I figured that out...
[04:18] <__keybuk> now running when either foo or bar or both are not running
[04:18] <AStorm> But then, both foo and bar have  to be started?
[04:18] <AStorm> Ah, either? Really?
[04:18] <__keybuk> yes, not ... and
[04:19] <AStorm> This "and" is nonintuitive :D
[04:19] <__keybuk> err, why?
[04:19] <__keybuk> it's boolean
[04:19] <AStorm> Actually... yep, it's alright.
[04:19] <AStorm> 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] <AStorm> :|
[04:23] <AStorm> What would: on (with foo or with bar) mean?
[04:23] <AStorm> Either one of them, but stop if any of them is stopped?
[04:24] <AStorm> 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] <AStorm> 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] <AStorm> with sounds like a "need" dependency
[04:26] <AStorm> almost exactly.
[04:27] <__keybuk> what are the different deps?
[04:27] <AStorm> Ok: use and need
[04:28] <AStorm> There are 2 special orderings: before and after
[04:28] <AStorm> (which map directly to "on")
[04:29] <AStorm> Well, before doesn't actually.
[04:29] <AStorm> It works like a "pre-start", but isn't tightly bound to the job.
[04:30] <AStorm> after x == on x started
[04:31] <AStorm> need x == with x
[04:31] <AStorm> use x is special. Like a conditional after.
[04:32] <AStorm> 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] <AStorm> Yes, if it's "added" to the "runlevel"
[04:33] <AStorm> Doesn't map directly to events.
[04:33] <AStorm> __keybuk, yes.
[04:33] <AStorm> Or, when it's started, it pulls these as dependencies
[04:34] <AStorm> So, it would be like: foo has "need bar"
[04:34] <AStorm> if foo is started, bar is pulled in
[04:34] <AStorm> if foo is stopped, bar is removed (or not, in case of Gentoo init - but that's a misfeature)
[04:34] <AStorm> (should be removed when nothing else "needs" it)
[04:35] <AStorm> when bar is stopped, foo is stopped too.
[04:36] <AStorm> 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] <AStorm> Hmm. there would be 4 conditions:
[04:37] <AStorm> foo is started -> bar is started
[04:38] <AStorm> foo is stopped -> nothing needs bar -> bar is stopped
[04:38] <AStorm> foo is stopped -> something needs bar -> nop
[04:38] <AStorm> foo is started -> bar is started -> bar is stopped -> everything needing bar is stopped
[04:38] <AStorm> (including foo)
[04:39] <AStorm> This would be hard to implement nicely with autoresurrecting services.
[04:40] <AStorm> 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] <AStorm> Yes.
[04:42] <AStorm> But the hardest part is "something needs bar -> nop"
[04:42] <__keybuk> why would it nop?
[04:43] <AStorm> Because something else besides foo requires it.
[04:43] <AStorm> so in this case, stopping foo shouldn't stop bar
[04:43] <AStorm> while when only foo needs bar, bar should be stopped
[04:43] <AStorm> Would require another event, let's say "lastneed"
[04:44] <AStorm> or rather "noneed"
[04:44] <AStorm> A simplel integer counter :P
[04:44] <AStorm> bar noneed would be fired if it reaches zero
[04:45] <AStorm> decreased when something needing bar is stopped
[04:45] <AStorm> increased when something needing bar is started
[04:48] <AStorm> Usually it's implemented using a stack and not events.
[04:48] <AStorm> s/stack/array/
[05:03] <AlexExtreme> __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] <AlexExtreme> ah
[05:05] <AlexExtreme> k :)
[05:05] <AlexExtreme> 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] <AlexExtreme> k
[05:06] <AlexExtreme> 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] <AlexExtreme> 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.
[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] <AlexExtreme> hmm
[05:30] <AlexExtreme> 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] <AlexExtreme> 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] <AlexExtreme> 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] <AlexExtreme> 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] <AlexExtreme> hmm
[05:44] <AlexExtreme> so STATE would be true if it is started?
[05:44] <AlexExtreme> and false if stopped?
[05:45] <__keybuk> right
[05:46] <AlexExtreme> ok
[05:46] <_ion> That syntax doesn't look bad.
[05:46] <AlexExtreme> 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] <AlexExtreme> yes
[05:55] <__keybuk> doesn't solve all of the problems though, I don't think
[05:58] <AStorm> __keybuk, for the fsck, in order to get the device ID, use udevinfo --name=<partition> --query=env | grep ID_PATH
 __keybuk, in the replacement-initscripts branch, what is getmntent for?
 AlexExtreme: parsing /etc/fstab and /etc/mtab properly
 and not using grep or $IFS
 which are both broken if you want spaces in your mount points :p
[05:59] <AlexExtreme> note the grep part ;)
[06:01] <__keybuk> AStorm: udev is not a database :P
[06:22] <AStorm> __keybuk, udev knows the device ID.
[06:22] <AStorm> getmntent doesn't know which device you're scanning :P
[06:23] <AStorm> So, you would mount many things from one device at once. (unless watershed is powerful enough to avoid that)
[06:23] <AStorm> /dev/sda1 and /dev/mapper/wtf may be on the same device.
[06:23] <AStorm> Udev knows about these, so does sysfs
[06:24] <AlexExtreme> as far as I can tell getmntent also knows about that
[06:24] <AStorm> Not the device part.
[06:24] <AlexExtreme> it uses libvolume_id from udev
[06:25] <AStorm> So it doesn't tell you the data. :>
[06:25] <AStorm> try it on some DM or RAID volume.
[06:25] <AStorm> udevinfo also doesn't tell everything :/
[06:25] <AStorm> ls-ing /sys/block/.../slaves tells more
[06:26] <AStorm> or ls-ing /sys/block/.../holders instead
[06:26] <AStorm> But how to resolve /dev/mapper/wtf to dm-0?
[06:27] <AStorm> Blah@me
[06:27] <AStorm> dmsetup table...
[06:27] <AStorm> (but that requires cut use)
[06:51] <__keybuk> AStorm: devmap_name
[06:51] <__keybuk> (on Ubuntu)
[06:52] <AStorm>        Invoking the command as devmap_name is equivalent to
[06:52] <AStorm>        dmsetup info -c --noheadings -j major -m minor.
[06:52] <AStorm> 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
[08:20] <phsdv> 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] <phsdv> you can find the script here: http://upstart.pauldevries.homelinux.com/wp-content/uploads/fs-check.txt
[08:22] <phsdv> It does not check the root partition, that will be dealt with seperately
[08:22] <AlexExtreme> yess
[08:23] <AlexExtreme> *yes
[08:23] <AlexExtreme> emit fs-checked $partition << shouldn't that be 'initctl emit fs-checked $partition' ?
[08:23] <phsdv> yes, I made a link
[08:23] <AlexExtreme> ab
[08:23] <AlexExtreme> *ah
[08:23] <AlexExtreme> ok
[08:24] <phsdv> In this way you only have one fsck per block device at a time.
[08:24] <phsdv> and you can have multiple block devices checked in paralel
[08:25] <phsdv> it probably does not handle yet names with spaces in there. But adding some "" should help out there
[08:28] <phsdv> 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] <phsdv> I still need to get rid of the sleep statement though :(
[08:29] <AlexExtreme> ok
[08:29] <phsdv> If I do not wait, I get errors...
[08:29] <AlexExtreme> i'll look at it later, i need to go now :)
[08:29] <phsdv> 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] <phsdv> no, not yet
[08:33] <phsdv> but I do not have experience with LVM and RAID