| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| === zarul [n=rs@60.49.92.185] has joined #upstart | ||
| === zarul [n=rs@60.49.92.185] has left #upstart [] | ||
| === theCore [n=alex@unaffiliated/thecore] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === wasabi_ [n=wasabi@cpe-76-184-96-5.tx.res.rr.com] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === wasabi_ [n=wasabi@ubuntu/member/wasabi] has joined #upstart | ||
| === psibox_ [n=dreger@smart.physik.fu-berlin.de] has joined #upstart | ||
| === jonibo [n=jonas@213.212.2.215] has joined #upstart | ||
| === Keybuk [n=scott@quest.netsplit.com] has joined #upstart | ||
| === Md [i=md@freenode/staff/md] has joined #upstart | ||
| === Amaranth [n=travis@ubuntu/member/amaranth] has joined #upstart | ||
| Keybuk | thom: no new spam since requiring ajax comments | 12:40 |
|---|---|---|
| Keybuk | sweet | 12:40 |
| === Seveas [n=seveas@ubuntu/member/seveas] has joined #upstart | ||
| thom | noice | 01:48 |
| Keybuk | now I just have to delete the 50 pages of spam that appeared in the last week <g> | 01:48 |
| === Keybuk wishes there were a way to increase the page size | ||
| thom | heh, yeah, did that for trackback spam yesterday | 01:49 |
| thom | presumably page size is template dependent? | 02:02 |
| Keybuk | no idea | 02:02 |
| Keybuk | I mean the size of the feedback admin page | 02:02 |
| Keybuk | 40 is too low | 02:02 |
| thom | ah, right | 02:04 |
| thom | yeah | 02:04 |
| Keybuk | thom: (re: laptops) I'd guess you'd be championing the Lenovo still? | 02:13 |
| thom | yep, my x60s is awesome love | 02:13 |
| thom | (and core 2 duo parts should be available soon) | 02:13 |
| Keybuk | still no touchpad though | 02:16 |
| thom | feature not bug | 02:16 |
| Keybuk | for you maybe | 02:17 |
| Keybuk | I can't use the nipples | 02:17 |
| thom | that explains a lot *g* | 02:17 |
| Keybuk | the Dell D420 looks nice | 02:18 |
| thom | but Dull. | 02:19 |
| Keybuk | why Dull? | 02:20 |
| thom | generic term for dell, innit. i've never been impressed with their build quality | 02:21 |
| Keybuk | the build quality of the new Lenovos some people had at UDS didn't look great either, tbh | 02:22 |
| thom | and i know what you do to laptops | 02:22 |
| Keybuk | the new HPs looked fairly rugged | 02:22 |
| thom | yeah? not seen one | 02:22 |
| Keybuk | and jdub's Dell looked pretty rugged too | 02:22 |
| thom | the lenovos around here have taken some pretty hefty battering | 02:22 |
| Keybuk | someone had one of the new T? series Lenovo - 15" thing | 02:23 |
| Keybuk | the case had already cracked, and they'd only had it a month or two | 02:23 |
| Keybuk | I don't really want a 14" laptop though, 12" is what I'm after, and Lenovo don't have a good range | 02:23 |
| Keybuk | very few options, underpowered comparatively to others in the same range, no touchpad, etc. | 02:24 |
| Keybuk | screen is somewhat small now too | 02:24 |
| Keybuk | somewhat low-res, I should say | 02:25 |
| thom | yeah, 1024x768 is about my only complaint | 02:42 |
| Keybuk | everyone with an X60 at UDS/AllHands had severe problems getting them to work with projectors | 02:44 |
| Keybuk | have you had that? | 02:44 |
| thom | never tried | 02:44 |
| thom | i'm pretty sure ross has his working though | 02:44 |
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| Keybuk | AlexExtreme: ping | 05:58 |
| AlexExtreme | Keybuk, pong | 05:58 |
| Keybuk | AlexExtreme: need an e-mail address for the ChangeLog | 05:58 |
| Keybuk | is alex@alex-smith.me.uk ok? | 05:58 |
| AlexExtreme | yes, that's the right one :) | 05:58 |
| Keybuk | thanks | 05:59 |
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| _ion | keybuk: Shouldn't TEST_FILE_RESET in nih/test.h have do { } while (0) around the definition? | 06:53 |
| Keybuk | _ion: yes, probably | 06:54 |
| _ion | http://johan.kiviniemi.name/tmp/nih_test.h.diff | 06:56 |
| Keybuk | thanks | 07:04 |
| === Keybuk is particularly proud of TEST_CHILD <g> | ||
| _ion | Yeah, it's neat. :-) | 07:06 |
| Keybuk | TEST_FILENAME needs a do { } while (0) too | 07:18 |
| Keybuk | AlexExtreme: did you ever solve bug #69950 ? | 07:36 |
| AlexExtreme | it's a splashy bug I think | 07:38 |
| AlexExtreme | so close it if you want | 07:38 |
| === ..[topic/#upstart:Keybuk] : Upstart 0.3.1 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/ | http://upstart.ubuntu.com/doc/getting-started.html | irc logs: http://people.ubuntu.com/~fabbione/irclogs | ||
| AlexExtreme | whoo, 0.3.1 ;) | 07:47 |
| Keybuk | 28 files changed, 3020 insertions(+), 5350 deletions(-) | 07:47 |
| Keybuk | 26 files changed, 4891 insertions(+), 7806 deletions(-) | 07:48 |
| Keybuk | (upstart and nih) | 07:48 |
| AlexExtreme | cool | 07:48 |
| Keybuk | quite an impressive code changage, mostly confirmed to the unit tests :p | 07:48 |
| Keybuk | confined, even, not confirmed | 07:48 |
| Keybuk | heh | 07:48 |
| AlexExtreme | :) | 07:49 |
| === phsdv [n=paul@dyn-83-156-76-20.ppp.tiscali.fr] has joined #upstart | ||
| === wasabi [n=jhaltom@ubuntu/member/wasabi] has joined #upstart | ||
| === juergbi [n=juerg@80-219-26-249.dclient.hispeed.ch] has joined #upstart | ||
| === AlexExtreme tests 0.3.1 | ||
| AlexExtreme | brb | 08:15 |
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| AlexExtreme | seems to work ok | 08:26 |
| Keybuk | :-) | 08:26 |
| Keybuk | it's not much different from 0.3.0, other than the minor bug fixes | 08:26 |
| AlexExtreme | yeah | 08:27 |
| AlexExtreme | now, i can play with syslog-ng sometime | 08:27 |
| AlexExtreme | bbl | 08:30 |
| Keybuk | hmm | 08:56 |
| Keybuk | my machine doesn't boot | 08:56 |
| Keybuk | I'm sure upgrading to 0.3.1 is a mere coincidence | 08:56 |
| Keybuk | la la la | 08:56 |
| Keybuk | *shrug* fine that time | 08:58 |
| Keybuk | weird | 08:58 |
| AlexExtreme | back | 08:59 |
| === maro reboots :) | ||
| AlexExtreme | heh, that's just annoying | 09:05 |
| AlexExtreme | i just bumped the gdm package, then a new gdm version gets release | 09:05 |
| AlexExtreme | *released | 09:05 |
| Keybuk | always the way | 09:07 |
| Keybuk | http://upstart.ubuntu.com/wiki/JobStates | 09:10 |
| Keybuk | ^ Would appreciate some eyes on that | 09:10 |
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| Keybuk | I think it's finally stable and actually correct | 09:10 |
| === AlexExtreme looks | ||
| maro | ah, nice, initctl list looks normal again :) | 09:10 |
| AlexExtreme | Keybuk, looks fine to me | 09:13 |
| AlexExtreme | (nice diagram, btw ;)) | 09:13 |
| Keybuk | wasabi: ^ | 09:13 |
| wasabi | hi | 09:21 |
| wasabi | oh ok | 09:21 |
| Keybuk | does that look right? | 09:24 |
| wasabi | reading | 09:24 |
| _ion | keybuk: Looks good. | 09:29 |
| === Keybuk [n=scott@syndicate.netsplit.com] has joined #upstart | ||
| wasabi | Keybuk: Random little thought I had while falling asleep. How does the system shutdown right now? | 09:34 |
| wasabi | And how should it shutdown? We've talked a lot about starting, but what about system teardown? | 09:34 |
| wasabi | There are two things I see, the teardown of existing jobs, then the execution of new jobs to put the machine into an off state | 09:34 |
| wasabi | There's obviously the shutdown signal? How should that be used appropiatly? | 09:35 |
| Keybuk | one moment | 09:35 |
| wasabi | I was just modeling it in my head... Say you have a "poweroff" task. Should that task be invoked on a signal named "shutdown"? Or is that task something which the user executes (by starting it using a control) | 09:36 |
| wasabi | s/signal/event/ | 09:36 |
| wasabi | If it was a task, it could do stuff like: for each mounted file system { emit file system unmounting; unmount; emit file system unmounted; } signal kernel to power off. | 09:37 |
| wasabi | The unmounting of every file system in turn obviously causes everything to stop. | 09:38 |
| Keybuk | right | 09:38 |
| Keybuk | so there's a couple of distinct parts to this | 09:38 |
| wasabi | And it can of course block on emitting both signals, causing it to wait until everything is shutdown. | 09:44 |
| wasabi | That introduces another interesting thing. Windows has this thing where some services consciously do not stop on poweroff. They don't go through the effort of anything. The system just powers off. | 09:44 |
| wasabi | They get the stop signal, but know it was caused by the system powering down, and so don't do any work. | 09:45 |
| wasabi | filesystem unmounted will be available to those jobs that start explicitly because of it, but it's also not a good indicator of the reason for the file system being unmounted. | 09:46 |
| wasabi | events being causes by other events, etc. Makes me wonder if $UPSTART_JOB should represent that stack. =) | 09:47 |
| wasabi | Err, $UPSTART_EVENT | 09:47 |
| wasabi | # The primary process is run when entering the start | 09:49 |
| wasabi | state. | 09:49 |
| wasabi | there's no "start" state defiend on the graph, just "exec process" | 09:50 |
| wasabi | minor inconsistency i suspect | 09:50 |
| wasabi | I really do feel that all events emitted internally should block though. | 09:52 |
| wasabi | perhaps just for consistency. | 09:52 |
| Keybuk | sorry, juggling a dozen things at once | 09:57 |
| wasabi | s'ok, me too | 09:57 |
| Keybuk | so right, two distinct parts | 09:57 |
| Keybuk | one is the services that are running; those I think will be defined in terms of other things | 09:57 |
| Keybuk | we can largely ignore them from a startup pov. because they're started as a side effect of things like "fhs filesystem", "networking", etc. | 09:58 |
| Keybuk | likewise I think we can ignore them from a shutdown pov, because they're stopped as a side effect of the same things going away | 09:58 |
| wasabi | yup | 09:58 |
| Keybuk | the side effect here is that it'd negate teardown a little | 10:01 |
| Keybuk | otoh, they'd all happen in parallel and most wouldn't have post-stop scripts | 10:01 |
| Keybuk | the goal of teardown was to avoid shell scripts that just did kill -TERM with some time-wasting stuff | 10:01 |
| Keybuk | we did the kill -TERM *anyway* since we sent kill signals | 10:01 |
| Keybuk | the real problem is the shutdown tasks | 10:02 |
| Keybuk | the mirror of the startup tasks | 10:02 |
| Keybuk | the startup tasks are chained off "startup", and do things like mount the filesystems | 10:02 |
| Keybuk | I think likewise, the shutdown tasks are chained off "shutdown" and do things like unmount them | 10:03 |
| wasabi | Is shutdown in fact an event? | 10:03 |
| wasabi | I know it is now. | 10:03 |
| wasabi | Is that right, is that proper? | 10:03 |
| Keybuk | it is currently | 10:03 |
| Keybuk | I think it has to be, as you need to do something to start bringing things down | 10:04 |
| wasabi | That seems more like using shutdown as a method call. | 10:04 |
| Keybuk | I tend to think of events as method calls anyway :p | 10:04 |
| wasabi | Heh. | 10:04 |
| wasabi | If "shutdown" was a job/task, would that be any different/better/whatever? | 10:04 |
| wasabi | Other than looking stupid: | 10:05 |
| wasabi | initctl shutdown start | 10:05 |
| Keybuk | I think that having it as a job is a little less flexible | 10:05 |
| Keybuk | you could only do one thing with it, by modifying that task | 10:05 |
| Keybuk | by having it as an event, you can write any number of tasks to happen simultaneously | 10:05 |
| wasabi | Well, depends how you want to take it. What happens, in what order, on shutdown? | 10:05 |
| Keybuk | e.g. bring the filesystem and network down at once | 10:05 |
| Keybuk | shutdown is tiny | 10:05 |
| wasabi | You can do that too. The task can emit furthur signals. | 10:05 |
| Keybuk | kill all processes | 10:05 |
| Keybuk | unmount filesystems | 10:06 |
| wasabi | With more specific meanings. | 10:06 |
| Keybuk | reboot() | 10:06 |
| wasabi | Are we commiting to reversing the killall processes with unmounting file systems? | 10:06 |
| Keybuk | right, but I think that it's better that if a distro wants to do that, they write a task that emits those signals "on shutdown" | 10:06 |
| Keybuk | more flexible | 10:06 |
| Keybuk | reversing? | 10:06 |
| wasabi | hmm. | 10:06 |
| wasabi | well, we are no longer going to kill anything in direct response to shutdown. | 10:06 |
| wasabi | Them stoppnig will be a byproduct of their dependencies becoming unavailable: | 10:07 |
| wasabi | networking, file systems. | 10:07 |
| wasabi | That's what makes me think about the shutdown task. | 10:07 |
| Keybuk | you'd still need an equivalent to "killall -TERM" | 10:07 |
| Keybuk | otherwise you can't unmount the filesystems | 10:07 |
| wasabi | It can do the work of unmounting the file systems, which indirectly emit filesystem-unmounting, and bring down services. | 10:08 |
| _ion | Can't you do a lazy unmount? | 10:08 |
| wasabi | And then it can do the work of killall -TERM. | 10:08 |
| wasabi | Where is that work going? | 10:08 |
| Keybuk | _ion: shutdown ... kinda critical it happens before we power off :p | 10:08 |
| wasabi | Hmm... interesting thing, we aren't actually unmounting file systems on shutdown, either... | 10:08 |
| wasabi | We are just making them RO, aren't we? | 10:09 |
| Keybuk | wasabi: I figured there'd be a shutdown task started by the shutdown event :) | 10:09 |
| Keybuk | wasabi: currently we unmount them | 10:09 |
| Keybuk | we make the root ro | 10:09 |
| wasabi | even /? | 10:09 |
| _ion | kebyuk: Ah. :-) | 10:09 |
| wasabi | And there is some sort of guarentee that /bin is on the same fs as / | 10:09 |
| wasabi | heh | 10:09 |
| wasabi | guess there'd have to be he | 10:09 |
| wasabi | and /usr shouldn' tmatter. | 10:10 |
| Keybuk | yeah, you can't have /bin and /sbin different to / :) | 10:10 |
| Keybuk | otherwise you don't have /sbin/init and /bin/sh <g> | 10:10 |
| wasabi | So, the shutdown task loops file systems, determines which it should unmount, does so, resulting in services stopping. | 10:10 |
| wasabi | I'm thinkiing this | 10:10 |
| Keybuk | windows services knowing stop was caused by poweroff ... | 10:11 |
| Keybuk | we have that now in two ways | 10:11 |
| Keybuk | 1) UPSTART_EVENT = "shutdown" | 10:11 |
| wasabi | for fs in / /usr /usr/local /var /whatever_some_user_has; do ( initctl emit fs-bye-bye $fs *BLOCKING*; umount $fs; initctl emit fs-gone ) *; done | 10:11 |
| wasabi | Err, that last * should be a & | 10:11 |
| Keybuk | 2) any event after shutdown (or not) can be matched using complex-event-config | 10:12 |
| wasabi | UPSTART_EVENT won't == shutdown. | 10:12 |
| wasabi | It will equal something sill like network-going-away | 10:12 |
| Keybuk | right | 10:12 |
| wasabi | s/sill/silly/ | 10:12 |
| wasabi | Which is what makes me wonder. Should UPSTART_EVENT be the stack? | 10:12 |
| Keybuk | it could be | 10:13 |
| wasabi | That wa you could go if [ $UPSTART_EVENT starts with "shutdown" ] | 10:13 |
| Keybuk | start state defined on graph => it's defined as the name of the "exec process" node in the text below the graph | 10:13 |
| wasabi | Another interesting thing... from the "shutdown" task. | 10:13 |
| wasabi | If it sees that an event it emits breaks, such as fs-umounting, it can revert. | 10:14 |
| wasabi | If /usr can't be umounted, it can log, then remount everything. | 10:15 |
| wasabi | or just issue "startup" again. | 10:15 |
| Keybuk | right | 10:15 |
| wasabi | That can go all the way down to being unable to remount / ro | 10:15 |
| Keybuk | started/stopped being blocking events => while it would be "consistent", they wouldn't actually block anything | 10:15 |
| wasabi | quite interesting. ;) | 10:15 |
| Keybuk | the interesting thing about the starting/stopping events is that they can actually block the job from starting or stopping | 10:15 |
| Keybuk | started/stopped are emitted at the end of a state transition -- so if they block, it has absolutely no effect | 10:16 |
| wasabi | That's true. | 10:16 |
| wasabi | You are right. ;) | 10:16 |
| Keybuk | so it'd be an extra code headache to produce no discernable effect :p | 10:17 |
| wasabi | I guess, what I'd be afraid of, is by making shutdown an event, is that other software will in fact attempt to shut itself down on shutdown. | 10:20 |
| Keybuk | no worry about that | 10:20 |
| Keybuk | e.g. getty :p | 10:20 |
| wasabi | When it should really not do so, it should wait for it's required resources to go away | 10:20 |
| wasabi | And I think there needs to be one entry task for the procedure of shutting down... so it can do network/filesystem/whatever and detect failures to revert both. | 10:21 |
| === maro [n=mark@0x55511dab.adsl.cybercity.dk] has joined #upstart | ||
| wasabi | network for instance doesn't go down in response to an event, it goes down because something tells it to. | 10:22 |
| Keybuk | (back in 15-30 min) | 10:23 |
| Keybuk | ok | 10:49 |
| Keybuk | yeah for the most part I agree | 10:49 |
| Keybuk | I think the reason I dislike having a forced shutdown task is that it's ... icky | 10:49 |
| Keybuk | of course, I guess we could define neither in upstart, and just let distros decide whether they do "initctl start shutdown" or "initctl emit shutdown" | 10:50 |
| Keybuk | but again, that's kinda icky, because it removes some consistency | 10:50 |
| Keybuk | they'd all have a different /sbin/shutdown | 10:50 |
| === theCore [n=alex@ubuntu/member/theCore] has joined #upstart | ||
| theCore | how often the bzr branch (http://bazaar.launchpad.net/~keybuk/upstart/main/) is sync'd? | 10:53 |
| Keybuk | te | 10:54 |
| Keybuk | theCore: dunno, hourly or so I guess | 10:54 |
| theCore | rev 23? | 10:54 |
| Keybuk | 297 | 10:54 |
| Keybuk | syndicate scott% bzr revno http://bazaar.launchpad.net/~keybuk/upstart/main/ | 10:54 |
| Keybuk | 297 | 10:54 |
| theCore | oh.... | 10:55 |
| theCore | nevermind | 10:55 |
| Keybuk | did you bzr pull? | 10:55 |
| theCore | yes | 10:55 |
| theCore | the tree is sync'd | 10:55 |
| Keybuk | ...but...? | 10:56 |
| theCore | bzr's wasn't clear | 10:56 |
| theCore | bzr's output | 10:56 |
| theCore | Using saved location: http://bazaar.launchpad.net/~keybuk/upstart/main/ | 10:56 |
| theCore | All changes applied successfully. | 10:56 |
| theCore | 23 revision(s) pulled. | 10:56 |
| theCore | I thought it was rev23 | 10:57 |
| Keybuk | ah, heh | 10:57 |
| Keybuk | nah, it means you got 23 new revisions | 10:57 |
| Keybuk | top one should be NEWS: Updated | 10:57 |
| theCore | yeah, I figured it out | 10:57 |
| theCore | bzr log -r 10..23 | 10:57 |
| theCore | was kinda weird | 10:57 |
| Keybuk | bzr log -r $(($(bzr revno) - 23).. | 10:58 |
| Keybuk | err | 10:58 |
| Keybuk | bzr log -r $(($(bzr revno) - 23)).. | 10:58 |
| Keybuk | :p | 10:58 |
| theCore | ah, I just found better way | 10:59 |
| theCore | bzr log -r -10... | 10:59 |
| theCore | er, bzr log -r -10.. | 10:59 |
| Keybuk | ooh | 10:59 |
| Keybuk | that's shiny | 10:59 |
| Keybuk | I didn't know about that <g> | 11:00 |
| theCore | me, either | 11:00 |
| Keybuk | theCore: pushed the "Bump version to 0.3.2" revision | 11:04 |
| Keybuk | see how long that takes to show up | 11:04 |
| theCore | ah, I know what I am going to do | 11:07 |
| theCore | I will translate upstart in French :) | 11:08 |
| Keybuk | sweet | 11:09 |
| Keybuk | I haven't yet worked Rosetta out | 11:09 |
| Keybuk | I'm vaguely nagging for it to just have a bzr branch with the translated po files on it :) | 11:12 |
| Keybuk | so I can just bzr merge http://rosetta.launchpad.net/products/upstart | 11:12 |
| Keybuk | :p | 11:12 |
| theCore | oh | 11:14 |
| Keybuk | I click a button, it sends me a tarball | 11:15 |
| Keybuk | all seems a bit ... primitive | 11:16 |
| theCore | Writing in French with a English keyboard is painful | 11:17 |
| theCore | I almost never write in French | 11:18 |
| theCore | I only speak it | 11:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!