[02:06] <Keybuk> refactoring is such great fun
[02:27] <ion_> Heh
[02:28] <AlexExtreme> why's that? :)
[02:37] <Keybuk> cleaned up event.c a little bit
[02:37] <AlexExtreme> cool
[02:37] <Keybuk> got rid of the evily named EventEmission structure
[02:38] <Keybuk> (that's now just Event)
[02:38] <Keybuk> (and what was Event is now EventInfo)
[02:38] <Keybuk> also added some ref-counting stuff, so we can keep Event information around after it's been handled (since it populates environment, etc.)
[02:42] <Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070520120917-6yanaj1t0a1ej3zd?start_revid=scott%40netsplit.com-20070520121451-6273as3mqxmumuai#init/job.c
[02:49] <ion_>          * should be releaed and the event should be freed.
[02:49] <ion_> test_event.c
[03:00] <Keybuk> :-)
[03:00] <Keybuk> next thing to figure out is what the difference between Jobs and States means
[03:02] <Keybuk>  * should they be configured in different directories?
[03:03] <Keybuk>    or should they be the same, just without processes specified
[03:03] <Keybuk>    - if different, how do we avoid name clashes?
[03:03] <Keybuk>    - if the same, how do we prevent "start STATE" from working?
[03:03] <Keybuk>      and what happens if you turn a file from a job to a state or vice-versa?
[03:05] <AlexExtreme> if it's the same, can't you prevent start STATE from working by having init work out whether it is a state, and if it is chuck back an error and bail out?
[03:05] <AlexExtreme> or is it not possible to work out?
[03:07] <ion_> Perhaps the use cases should be considered to determine that.
[03:07] <ion_> That is, what Keybuk said.
[03:21] <Keybuk> what I want to avoid is having the entire Job structure around for a State
[03:21] <Keybuk> otherwise, what's the difference?
[03:21] <Keybuk> I can see two easy ways to do that
[03:21] <Keybuk> one is to have a states hash, as well as a jobs hash, and have something evil in cfgfile.c that returns State instead of Job if there's no processes configured, etc.
[03:22] <Keybuk> but you'd then have to look in both hashes all the time
[03:24] <Keybuk> the other way would be to get rid of the jobs hash
[03:24] <Keybuk> instead have a "registry"
[03:24] <Keybuk> that'd probably have several levels
[03:24] <Keybuk> 1) configuration directory (e.g. /etc/??, ~/.??, etc.)
[03:25] <Keybuk> 2) filename
[03:25] <Keybuk> 3) state or job found there
[03:25] <Keybuk> and hash at (3)
[03:25] <Keybuk> that way, a file that defines both a state and a job (ie. an ordinary job) would be able to used as either a state or a job
[03:25] <Keybuk> but a file that defined just a state could only be used as a state
[03:25] <Keybuk> also that makes -HUP easy ;P
[03:26] <Keybuk> and I could move all the "replacement" stuff into that
[03:27] <Keybuk> (though when do you replace a State file?)
[04:30] <Keybuk> I guess the major question is: does it make sense to let sysadmins manually start/stop a "state" ?
[04:30] <Keybuk> e.g. if you've defined "user-can-login" as a state
[04:31] <Keybuk> (or writable-filesystem, filesystem-and-networking, etc.)
[04:38] <AlexExtreme> i don't think it makes sense, really. they aren't processes, so you should really be able to start/stop them. and if you have a case where a state hasn't really been reached, yet the sysadmin still starts it, it could cause some problems
[04:39] <AlexExtreme> so in the long run it'd be less problematic, IMO
[04:40] <ion_> I cant think of a state a sysadmin would need to start or stop manually. I cant think clearly with this flu in addition to my usual symptoms, though. :-)
[04:41] <Keybuk> hmm
[04:41] <Keybuk> so better question, should you be able to have a pre-start and/or post-stop script for a state?
[04:46] <AlexExtreme> hmm
[04:46] <AlexExtreme> i'm not sure...
[04:46] <AlexExtreme> i can't really think of a use case for that
[04:47] <ion_> How about having a process ping a remote host every once in a while and set a network-reachable state based on the pong?
[04:47] <AlexExtreme> at the moment we can create a job without a main process, just a pre-start and post-stop. are those states or are they still jobs?
[04:48] <Keybuk> exactly
[04:49] <Keybuk> use case: runlevel-2 state that sets utmp on the way in?
[04:49] <AlexExtreme> hmm
[04:49] <AlexExtreme> yes
[04:49] <Keybuk> user-can-login state that removes /etc/nologin on the way in, touches it on the way out?
[04:49] <AlexExtreme> yep
[04:50] <Keybuk> I can think of examples that are "nice"
[04:50] <Keybuk> and can't think of any counter-reasons why it should be forbidden
[04:50] <ion_> Yeah, definitely.
[04:50] <AlexExtreme> yep
[04:54] <Keybuk> which means that "State" would need the same internal state machine as "Job"
[04:54] <Keybuk> along with the ability to define processes, and their environment
[04:54] <Keybuk> so the difference between a state and a service is purely semantic
[05:06] <Keybuk> that makes things much easier, since it answers the questions like how to decide when to replace a state definition with one from an updated config file
[05:07] <ion_> Defining states just as jobs without a main process follows the KISS principle.
[06:00] <Keybuk> yeah
[06:07] <keir> i have a possibly rude question: how long until upstart begins shrinking boot time via parallel process start, etc?
[06:07] <AlexExtreme> it already can do
[06:07] <AlexExtreme> it'll *probably* be available in ubuntu 7.10
[06:10] <keir> i don't mind long boots on my desktop, but they are killer on my laptop
[06:10] <keir> especially since suspend is broken
[06:10] <Keybuk> it's interesting how hating the first normally co-incides with being affected by the 2nd :p
[06:11] <keir> heh
[06:11] <keir> i dream of fresh-install XP SP2 boot times for ubuntu
[06:11] <keir> now that os boots fast!
[06:12] <Keybuk> only the first time ...
[06:12] <cortana> but if you add up all the times you _have_ to boot it, i wonder which one eats a larger chunk of one's life
[06:16] <keir> true! but i used to run it on my laptop for old games
[06:16] <keir> i only had FF and the games installed
[06:16] <keir> i always got very jealous when it would boot up in 15 seconds or so
[06:17] <cortana> it's a good thing that winodws boots in about 20-25 seconds
[06:17] <cortana> i have to reboot about 3-4 times ususally to get my keyboard to work
[06:18] <Keybuk> Upstart's primary goal isn't to make boot faster
[06:18] <keir> Keybuk, i know
[06:18] <Keybuk> it's too make it more reliable and robust
[06:18] <cortana> there is a totally random 75% chance that my keyboard will _not_ work on any given boot into xp :(
[06:18] <Keybuk> as well as provide more flexibility for what's actually running
[06:18] <keir> Keybuk, it'd be great if that was a side effect :)
[06:18] <Keybuk> we just happen to also think it will speed it up
[11:01] <quitte> hi. has anyone tried compiling upstart using uclibc? I get this error:child.c: In function 'nih_child_poll': child.c:141: error: 'WEXITED' undeclared (first use in this function) WNOWAIT is also undeclared
[12:10] <quitte> now I'm getting undefined reference to `inotify_add_watch. do you happen to know what is missing in uclibc for that,too?
[12:12] <Keybuk> sys/inotify.h
[12:13] <quitte> hmm. that should comefrom the kernel, not uclibc?
[12:14] <Keybuk> the libc still has to define the syscall
[12:14] <quitte> ah
[12:20] <quitte> it's already there. what is this nih thing?
[12:23] <Keybuk> it's the standard library that upstart uses
[12:23] <Keybuk> like glib, or something