| === 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 | ||
| __keybuk | complex-event-config is complex :-/ | 03:24 |
|---|---|---|
| AlexExtreme | :/ | 03:25 |
| __keybuk | for example: | 03:25 |
| __keybuk | on starting apache until stopped apache and starting dbus until stopped dbus | 03:25 |
| __keybuk | do we stop apache from starting until dbus is starting? :p | 03:26 |
| AlexExtreme | hmmm | 03:27 |
| AlexExtreme | good point | 03:28 |
| AlexExtreme | that would be the only way to do it | 03:28 |
| 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:29 |
| __keybuk | so if dbus never starts, neither would apache? | 03:30 |
| AlexExtreme | yes | 03:30 |
| AlexExtreme | but that's a bit stupid | 03:30 |
| AlexExtreme | because it introduces an unnecessary dependency on dbus for apache | 03:31 |
| __keybuk | indeed | 03:32 |
| AStorm | Proper way would be to rewrite it into: | 03:53 |
| 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:54 |
| 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:55 |
| __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:56 |
| __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:57 |
| __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:58 |
| __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. | 03:59 |
| __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:00 |
| 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:01 |
| __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:02 |
| __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:03 |
| __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:04 |
| __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:06 |
| AStorm | Hmm... | 04:09 |
| AStorm | How would one do then failover services, which would be something like: | 04:10 |
| AStorm | -start when any of foo, bar started | 04:11 |
| AStorm | -stop when both of foo, bar stopped | 04:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| AStorm | "on" won't reset. | 04:15 |
| AlexExtreme | or whatever ;) | 04:15 |
| __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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| __keybuk | which is why I haven't coded it yet | 04:20 |
| __keybuk | and also acts strangelty | 04:20 |
| AStorm | :| | 04:20 |
| 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:23 |
| 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:24 |
| __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:25 |
| AStorm | with sounds like a "need" dependency | 04:26 |
| AStorm | almost exactly. | 04:26 |
| __keybuk | what are the different deps? | 04:27 |
| AStorm | Ok: use and need | 04:27 |
| AStorm | There are 2 special orderings: before and after | 04:28 |
| AStorm | (which map directly to "on") | 04:28 |
| AStorm | Well, before doesn't actually. | 04:29 |
| AStorm | It works like a "pre-start", but isn't tightly bound to the job. | 04:29 |
| AStorm | after x == on x started | 04:30 |
| AStorm | need x == with x | 04:31 |
| AStorm | use x is special. Like a conditional after. | 04:31 |
| AStorm | Wrong. Like a conditional need. | 04:32 |
| __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:33 |
| 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:34 |
| AStorm | when bar is stopped, foo is stopped too. | 04:35 |
| === int0x0c [n=ben@161.253.47.141] has joined #upstart | ||
| AStorm | It probably is possible to emulate using events alone, but isn't easy. | 04:36 |
| __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:37 |
| 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:38 |
| AStorm | This would be hard to implement nicely with autoresurrecting services. | 04:39 |
| AStorm | It would mean, when bar is restarted, restart everything needing it | 04:40 |
| __keybuk | that works with the events at the moment | 04:41 |
| __keybuk | since a job that's respawned emits stopping, starting, started | 04:41 |
| AStorm | Yes. | 04:42 |
| AStorm | But the hardest part is "something needs bar -> nop" | 04:42 |
| __keybuk | why would it nop? | 04:42 |
| 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:43 |
| 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:44 |
| AStorm | decreased when something needing bar is stopped | 04:45 |
| AStorm | increased when something needing bar is started | 04:45 |
| AStorm | Usually it's implemented using a stack and not events. | 04:48 |
| AStorm | s/stack/array/ | 04:48 |
| AlexExtreme | __keybuk, in the replacement-initscripts branch, what is getmntent for? | 05:03 |
| __keybuk | AlexExtreme: parsing /etc/fstab and /etc/mtab properly | 05:04 |
| __keybuk | and not using grep or $IFS | 05:04 |
| __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:05 |
| __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:06 |
| __keybuk | I also intend to add an option to output FOO=... fields for use with udev | 05:11 |
| __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:12 |
| __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:13 |
| === j_ack [n=rudi@p508DAAE9.dip0.t-ipconnect.de] has joined #upstart | ||
| === __keybuk is wondering whether "until" is unnecessary | ||
| __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:29 |
| AlexExtreme | hmm | 05:30 |
| AlexExtreme | all it does then is shortens things? | 05:30 |
| __keybuk | complicates things | 05:31 |
| __keybuk | thinking about whether it's better to make states a first-class thing, rather than something that can be defined with until | 05:32 |
| __keybuk | so | 05:35 |
| __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:36 |
| __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:38 |
| 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:39 |
| __keybuk | then add | 05:40 |
| __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:41 |
| 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:42 |
| __keybuk | not sure that solves the issue though | 05:43 |
| AlexExtreme | hmm | 05:44 |
| AlexExtreme | so STATE would be true if it is started? | 05:44 |
| AlexExtreme | and false if stopped? | 05:44 |
| __keybuk | right | 05:45 |
| AlexExtreme | ok | 05:46 |
| _ion | That syntax doesn't look bad. | 05:46 |
| AlexExtreme | yeah | 05:46 |
| __keybuk | for the networking and filesystem case, you'd need: | 05:51 |
| __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:52 |
| AlexExtreme | yes | 05:54 |
| __keybuk | doesn't solve all of the problems though, I don't think | 05:55 |
| AStorm | __keybuk, for the fsck, in order to get the device ID, use udevinfo --name=<partition> --query=env | grep ID_PATH | 05:58 |
| AlexExtreme | <AlexExtreme> __keybuk, in the replacement-initscripts branch, what is getmntent for? | 05:59 |
| AlexExtreme | <__keybuk> AlexExtreme: parsing /etc/fstab and /etc/mtab properly | 05:59 |
| AlexExtreme | <__keybuk> and not using grep or $IFS | 05:59 |
| AlexExtreme | <__keybuk> which are both broken if you want spaces in your mount points :p | 05:59 |
| AlexExtreme | note the grep part ;) | 05:59 |
| __keybuk | AStorm: udev is not a database :P | 06:01 |
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| AStorm | __keybuk, udev knows the device ID. | 06:22 |
| AStorm | getmntent doesn't know which device you're scanning :P | 06:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| AStorm | or ls-ing /sys/block/.../holders instead | 06:26 |
| AStorm | But how to resolve /dev/mapper/wtf to dm-0? | 06:26 |
| AStorm | Blah@me | 06:27 |
| AStorm | dmsetup table... | 06:27 |
| AStorm | (but that requires cut use) | 06:27 |
| === AStorm [n=astralst@chello084010114027.chello.pl] has left #upstart ["Bye"] | ||
| === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart | ||
| __keybuk | AStorm: devmap_name | 06:51 |
| __keybuk | (on Ubuntu) | 06:51 |
| 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:52 |
| __keybuk | $MAJOR and $MINOR in the uevent | 06:54 |
| === phsdv [n=paul@dyn-83-152-239-123.ppp.tiscali.fr] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| 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:20 |
| === AlexExtreme looks | ||
| phsdv | It does not check the root partition, that will be dealt with seperately | 08:22 |
| AlexExtreme | yess | 08:22 |
| 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:23 |
| 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:24 |
| phsdv | it probably does not handle yet names with spaces in there. But adding some "" should help out there | 08:25 |
| 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:28 |
| 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:29 |
| _ion | It doesn't take LVM, RAID etc. into account. | 08:32 |
| _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 | 08:33 |
| === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart | ||
| === pornflake [n=garret@Ta56c.t.pppool.de] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!