| _ion | Hm, Keybuk hasn't been here for three days. | 12:42 |
|---|---|---|
| === j_ack [n=rudi@p508DB835.dip0.t-ipconnect.de] has joined #upstart | ||
| === osx5 [n=danielka@c-24-3-201-47.hsd1.mn.comcast.net] has joined #upstart | ||
| osx5 | hello | 02:16 |
| osx5 | anyone from freenode staff here? | 02:18 |
| AStorm | Md? | 02:18 |
| osx5 | k | 02:19 |
| === osx5 [n=danielka@c-24-3-201-47.hsd1.mn.comcast.net] has joined #upstart | ||
| osx5 | Md must be afk | 02:26 |
| _ion | How may we help you with upstart? | 02:27 |
| osx5 | I want a hostname cloak | 02:27 |
| osx5 | but thanks | 02:27 |
| osx5 | is upstart better/ | 02:28 |
| osx5 | ? | 02:28 |
| _ion | Well, yes. :-) | 02:28 |
| osx5 | what makes it better? | 02:29 |
| osx5 | I use darwin on mac osx | 02:29 |
| _ion | See the "How does it differ from launchd?" heading at http://www.netsplit.com/blog/articles/2006/08/26/upstart-in-universe | 02:32 |
| _ion | (Seems like the page's markup is broken) | 02:32 |
| osx5 | k | 02:32 |
| osx5 | I'm new to unix | 02:32 |
| osx5 | and linux | 02:32 |
| === AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
| === AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
| === osx5 [n=danielka@c-24-3-201-47.hsd1.pa.comcast.net] has joined #upstart | ||
| === space-m0nkey_ [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart | ||
| === space-m0nkey_ is now known as space-m0nkey | ||
| osx5 | will MD ever return? | 03:08 |
| _ion | Let me check his wereabouts from my surveillance equipment... | 03:09 |
| osx5 | lol | 03:09 |
| === osx5 [n=danielka@c-24-3-201-47.hsd1.pa.comcast.net] has left #upstart [] | ||
| === osx5 [n=danielka@c-24-3-201-47.hsd1.pa.comcast.net] has joined #upstart | ||
| osx5 | oh he left | 03:11 |
| osx5 | wonderful | 03:11 |
| osx5 | lol | 03:11 |
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart | ||
| === AStorm [n=astralst@host-81-190-179-124.gorzow.mm.pl] has joined #upstart | ||
| === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart | ||
| === wasabi__ [n=wasabi@cpe-76-184-96-5.tx.res.rr.com] has joined #upstart | ||
| === AlexExtreme [n=AlexExtr@frugalware/developer/AlexExtreme] has joined #upstart | ||
| === Md_ [i=md@freenode/staff/md] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === Md_ is now known as Md | ||
| _ion | Welcome back, Keybuk :-) | 10:35 |
| Keybuk | heyhey | 10:36 |
| Keybuk | "welcome back" ? :P | 10:36 |
| Keybuk | did I go somewhere? | 10:36 |
| _ion | For almost 3 days you did. ;-) | 10:37 |
| Keybuk | we call that a "weekend" :p | 10:38 |
| _ion | Hehe | 10:38 |
| Keybuk | "until" is causing me issues | 11:05 |
| _ion | Why is that? | 11:07 |
| Keybuk | well, how it should behave | 11:07 |
| Keybuk | simplest example: | 11:07 |
| Keybuk | foo until bar | 11:07 |
| Keybuk | I think it's pretty obvious that the job is running when foo happens, and stops running when bar happens | 11:07 |
| Keybuk | however ... if foo happens again after bar has happened, should the job be started again or not? | 11:08 |
| _ion | I do think it should. | 11:08 |
| Keybuk | I agree, simply on the basis that upstart shouldn't consider anything to be permanent | 11:09 |
| Keybuk | e.g. in an upstart system, you should be able to kill all processes, then issue the "startup" event again as a kind of soft reboot | 11:09 |
| _ion | Also, '(foo and baz) until bar': IMHO after bar, *both* foo and baz should happen again. | 11:10 |
| Keybuk | hang on, getting to that ;p | 11:10 |
| Keybuk | so, with the above example, we can implement until simply | 11:10 |
| Keybuk | it's just a tree node that is TRUE when the left becomes TRUE, and FALSE when the right becomes TRUE | 11:11 |
| Keybuk | no further handling is needed | 11:11 |
| Keybuk | so right, more complex example as you said | 11:11 |
| Keybuk | (foo or bar) until baz | 11:11 |
| Keybuk | I think that's pretty obvious; either foo or bar must happen for it to be started, baz stops it, and either foo or baz can start it again | 11:11 |
| _ion | Yeah, with the 'and' case the implementation definitely becomes more complex. | 11:12 |
| Keybuk | right | 11:13 |
| Keybuk | foo until (bar or baz) | 11:13 |
| Keybuk | that's still simple | 11:13 |
| Keybuk | and makes it more complex | 11:13 |
| Keybuk | (foo and bar) until baz | 11:13 |
| Keybuk | now, I think this should behave thus: | 11:13 |
| Keybuk | foo and bar need to happen in any order for the job to be started | 11:13 |
| Keybuk | baz happening stops it | 11:13 |
| Keybuk | after which, both foo and bar need to happen again | 11:14 |
| Keybuk | (rather than just one or the other happening) | 11:14 |
| _ion | Indeed. | 11:14 |
| Keybuk | so that makes the implementation a little more complex | 11:15 |
| Keybuk | when the right hand side is set to TRUE, the until node becomes FALSE *and* sets the left hand tree to FALSE | 11:16 |
| Keybuk | (ie. all nodes in the left hand tree) | 11:17 |
| Keybuk | does that sound sane? | 11:18 |
| _ion | Is '(foo until bar) until baz' supported? (I can't think of any use cases for it wouldn't it be exactly equivalent to 'foo until baz'?) | 11:22 |
| Keybuk | we'll get to that in a bit, thinking this one step at a time | 11:22 |
| Keybuk | foo until (bar and baz) | 11:22 |
| Keybuk | that's somewhat interesting | 11:23 |
| Keybuk | foo starts it, but bar and baz both need to happen to stop it | 11:23 |
| Keybuk | once stopped, only foo needs to happen to start it again; but both bar and baz need to happen again to stop it | 11:23 |
| Keybuk | so that implies that when the left hand side is set to TRUE, the until node becomes TRUE *and* sets all nodes on the right hand side to FALSE | 11:23 |
| _ion | Yes, it seems to me that nodes should be able to recursively set children to FALSE. | 11:25 |
| Keybuk | right | 11:25 |
| Keybuk | so (foo until bar) until baz | 11:25 |
| Keybuk | until | 11:26 |
| Keybuk | until baz | 11:26 |
| Keybuk | foo bar | 11:26 |
| Keybuk | foo has to happen for the tree to be TRUE | 11:26 |
| Keybuk | if either bar or baz happens, the tree becomes FALSE | 11:26 |
| _ion | Ah, right. | 11:27 |
| Keybuk | in either case, only foo needs to happen again for it to become TRUE again | 11:27 |
| Keybuk | so it's exactly equivalent to foo until (bar or baz) | 11:27 |
| _ion | So when baz happens, the topmost 'until' asks the child 'until' to set itself as FALSE, which doesn't need to do anything else than ask all its children to set themselves FALSE. | 11:29 |
| Keybuk | tight | 11:30 |
| Keybuk | right | 11:30 |
| _ion | (Thinking like OOP and recursive programming, of course the actual implementation doesn't need to be either object-oriented or recursive.) | 11:30 |
| Keybuk | *nods* | 11:32 |
| Keybuk | I actually have a non-recursive tree iterator in libnih | 11:32 |
| Keybuk | but anyway | 11:32 |
| Keybuk | right | 11:32 |
| Keybuk | so until is quite simple provided that all operators and operands are simple | 11:32 |
| _ion | Yeah, i remember skimming through that change. | 11:33 |
| Keybuk | lets introduce a less simple operator/operand | 11:33 |
| Keybuk | with JOB | 11:33 |
| Keybuk | how do we define that? | 11:33 |
| Keybuk | either its TRUE when the job's goal is START and FALSE when the job's goal is STOP | 11:33 |
| Keybuk | OR | 11:33 |
| Keybuk | its TRUE when the job's state is RUNNING and FALSE otherwise | 11:33 |
| Keybuk | OR | 11:33 |
| Keybuk | its FALSE when the job's state is WAITING and TRUE otherwise | 11:34 |
| Keybuk | <g> | 11:34 |
| _ion | :-) | 11:34 |
| _ion | Its use cases should probably be listed to find the answer. | 11:34 |
| Keybuk | the problem is it was defined over hot thai food | 11:34 |
| Keybuk | while we were crying and sweating | 11:34 |
| _ion | Hehe | 11:35 |
| Keybuk | and before we came up with the idea that "starting" and "stopping" should be blocking events | 11:35 |
| _ion | So, *are* there use cases for it that can't be done with the already existing things? | 11:35 |
| Keybuk | well... | 11:35 |
| Keybuk | obviously you can use until and the job events | 11:35 |
| Keybuk | starting JOB until stopped JOB | 11:36 |
| Keybuk | started JOB until stopping JOB | 11:36 |
| Keybuk | with the advantage that those retain the blocking behaviour | 11:36 |
| Keybuk | the actual use case for "with" was that you could place complex stanzas in a file that could be shared | 11:36 |
| Keybuk | and then just say "do whatever that one says" | 11:37 |
| Keybuk | it also happens to provide a "running with another job without blocking it" kind of syntax | 11:38 |
| _ion | What are the use cases for that? I.e. what are the jobs that should run 'with' another job without blocking it? | 11:43 |
| Keybuk | dunno | 11:44 |
| Keybuk | the main use case seems to be putting syntax in another file | 11:44 |
| _ion | For example, if there's a dummy job 'networking' with nothing but 'on' stanzas, i think it is good for a job using 'started networking until stopping networking' to block whatever 'networking' blocks. | 11:47 |
| Keybuk | a reasonable point | 11:47 |
| Keybuk | ok, so let's skip with for now | 11:58 |
| Keybuk | and think ahead to temporary events | 11:58 |
| Keybuk | "every hour" for example | 11:58 |
| Keybuk | every hour and network-up until network-down | 11:58 |
| Keybuk | pretty obvious; the "every hour" event triggers once an hour | 11:58 |
| Keybuk | and and combines that with the until, so it only gets used if the network is up | 11:58 |
| Keybuk | ... | 11:58 |
| Keybuk | every hour until some-event | 11:59 |
| Keybuk | that one is a bastard :p | 11:59 |
| _ion | Hmm... :-) | 11:59 |
| Keybuk | I think some of the problem is the words we're using | 12:00 |
| _ion | I can't think of anything else than starting it at every hour and stopping it when some-event happens. | 12:00 |
| _ion | Sorry, i mean: | 12:01 |
| Keybuk | if "foo until bar and frodo until bilbo" was actually "between foo and bar while between frodo and bilbo", it makes more sense | 12:01 |
| Keybuk | so it'd be obvious that "between every hour and some-event" behaves as you describe (which is how it would behave) | 12:01 |
| _ion | Start it at 00:00. Nothing changes until 03:12, when some-event happens. Start it at 04:00, until some-event happens again | 12:01 |
| Keybuk | right | 12:01 |
| Keybuk | English and Logic don't collide adequately | 12:02 |
| _ion | Heh | 12:02 |
| Keybuk | (the fact that in English, "foo until bar and frodo until bilbo" describes a period where either of the two is active (where logically it's when both are active) | 12:03 |
| Keybuk | and "foo until bar or frodo until bilbo" describes a period where only one of the two is active (when logically it's when either are active)) | 12:03 |
| _ion | Would substituting 'or', 'and', 'until' with |, &, -> respectively be too ugly? | 12:06 |
| _ion | The Finnish keymap also has :-) | 12:07 |
| _ion | Although i don't use it for anything else than writing Finnish specifically, it sucks for general use. :-) | 12:08 |
| Keybuk | I don't think the punctuation changes anything, as you'd still read it in English | 12:10 |
| Keybuk | http://upstart.ubuntu.com/wiki/ComplexEventConfig | 12:11 |
| Keybuk | ^ so that's a reworked draft | 12:11 |
| _ion | True. | 12:11 |
| === reppel [n=reppel@213-140-11-128.fastres.net] has joined #upstart | ||
| _ion | Looks nice. | 02:30 |
| === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart | ||
| === cortana [n=sam@62-31-146-25.cable.ubr12.azte.blueyonder.co.uk] has joined #upstart | ||
| === j_ack [n=rudi@p508D9227.dip0.t-ipconnect.de] has joined #upstart | ||
| === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart | ||
| _ion | keybuk: Have you had time to hack more on replacement-initscripts yet? | 06:51 |
| Keybuk | not yet | 06:52 |
| Keybuk | well | 06:52 |
| Keybuk | have been thinking and experimenting deeply with mounting filesystems | 06:52 |
| Keybuk | my original plan had been an instance job fired up each time a drive was mounted | 06:52 |
| _ion | That's actually what i wanted to ask about... | 06:52 |
| Keybuk | and the job was just to mount that path | 06:52 |
| Keybuk | and have a similar one for unmounting | 06:52 |
| Keybuk | but that doesn't work in the face of needing to mount /usr/local after /usr | 06:53 |
| _ion | Exactly. Have you got a solution yet? | 06:53 |
| === j_ack [n=rudi@p508D9227.dip0.t-ipconnect.de] has joined #upstart | ||
| === juergbi [n=juerg@80-219-17-102.dclient.hispeed.ch] has joined #upstart | ||
| _ion | An idea, probably filled with race conditions :-) : a file on RAM disk that contains the list of filesystems ready to be mounted. The 'fsck' job could contain 'echo "$DEVICE" | locked-write --append /ramdiskpath/mount; /sbin/initctl emit filesystem-checked -eDEVICE' and the 'mount' job would start on filesystem-checked and contain 'locked-read /ramdiskpath/mount | while read device ... ... for device in $ok_to_mount; do [mount them] ' | 06:59 |
| _ion | Feel free to punch holes in it. :-) | 07:00 |
| _ion | whatever starts on block-device-removed would have to remove the devices from the list while locking it. | 07:02 |
| _ion | That's what the mount job should do on successful mount, too. | 07:03 |
| AStorm | Keybuk, what about using dependencies to do this? :> | 07:09 |
| AStorm | Just add parametrised dependencies (e.g. use of $VALUE in deps) | 07:10 |
| Keybuk | I'm vaguely leaning towards just having a "mount -a" job and make sure that fails if at least one filesystem could not be mounted | 07:30 |
| _ion | How about ones being fsck'd? | 07:32 |
| Keybuk | aye, tricky | 07:33 |
| Md | Keybuk: check what suse does, I know that for a long time they have been running fsck/mount on demand triggered by uevents | 07:34 |
| Keybuk | Md: good point | 07:40 |
| Md | if all else fails, sleep for a while in a loop if the mount point does not exist | 07:43 |
| _ion | mountd? :-) | 07:45 |
| Keybuk | HAL! | 07:46 |
| Keybuk | sometimes I wish I worked for Apple | 07:46 |
| Keybuk | then I'd know everything was on the one filesystem | 07:47 |
| Keybuk | :p | 07:47 |
| _ion | Heh | 07:47 |
| Keybuk | SUBSYSTEM=="block", ACTION=="add", KERNEL=="sd*[0-9] |hd*[0-9] ", RUN+="mount.sh" | 07:49 |
| _ion | mount.sh does the fscking, too? | 07:49 |
| Keybuk | yup | 07:49 |
| Keybuk | (not that I had a handy vmware instance of opensuse around or anything ...) | 07:50 |
| _ion | And what does it do when there's /usr/local waiting for /usr? | 07:50 |
| Keybuk | it just runs mount -a after each fsck | 07:50 |
| _ion | I take it udev has a command queue, multiple mount.shs are never started simultaneously? | 07:52 |
| Md | no, they are | 07:53 |
| _ion | Does mount.sh contain locking then? | 07:53 |
| _ion | I probably should just grab the script from somewhere myself. :-) | 07:53 |
| === jonib1 [n=jonas@ua-83-227-144-18.cust.bredbandsbolaget.se] has joined #upstart | ||
| === thotz [n=thomas@d86-33-125-87.cust.tele2.at] has joined #upstart | ||
| === thotz [n=thomas@d86-33-125-87.cust.tele2.at] has left #upstart [] | ||
| === space-m0nkey [n=chatzill@client-82-3-73-143.manc.adsl.virgin.net] has joined #upstart | ||
| === phsdv [n=paul@dyn-83-152-232-59.ppp.tiscali.fr] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| Keybuk | _ion: it calls mount -a $DEVNAME | 09:14 |
| Keybuk | which is interesting | 09:14 |
| Keybuk | it doesn't seem to account for mountpoint not existing at all | 09:14 |
| === AStorm [n=astralst@chello084010114027.chello.pl] has joined #upstart | ||
| === mbiebl [n=michael@e180076146.adsl.alicedsl.de] has joined #upstart | ||
| === pkt [n=pantelis@athedsl-131388.otenet.gr] has joined #upstart | ||
| === j_ack [n=rudi@p508DA63E.dip0.t-ipconnect.de] has joined #upstart | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!