[00:21] <ion> #6  0xb7ff3eee in nih_file_read (parent=0x0, 
[00:21] <ion>     path=0xb800b094 "/sys/dev/block/8:1/../dev", length=0xbffff53c) at file.c:134
[00:21] <ion> mountall:file.c:134: Unhandled error from nih_file_read: Invalid or incomplete multibyte or wide character
[00:21] <ion> Wtf? :-P
[00:38] <ion> keybuk: A bug in nih_file_read: various errors cause a ‘goto error’, some of which set errno and some don’t. The error handler does nih_error_raise_system, potentially leading to nonsensical error messages.
[00:40] <ion> keybuk: I was trying to nih_file_read a sysfs file. Its stat says its size is 4096, whereas read actually returns 4 bytes. That caused the ‘Invalid or incomplete multibyte or wide character’ message.
[00:41] <ion> keybuk: Ah, you do set errno manually. I missed that.
[00:42] <ion> keybuk: I still think the error message for this case isn’t very helpful. :-)
[05:12] <ion> To ensure Keybuk notices this: hey, look at what i said on the other channel. :-P And now for some sleep.
[12:04] <ion> Morning
[12:04] <ion> keybuk: Online? :-)
[12:04] <Keybuk> yup
[12:04] <ion> Any comments about my patch?
[12:04] <Keybuk> patch?
[12:05] <ion> ti052526 < ion> keybuk: Here’s an untested implementation. It probably breaks your system and leaks memory, but it’s a start. Hey, at least it compiles without warnings. :-P  http://heh.fi/patches/mountall/
[12:05] <ion> ti052620 < ion> keybuk: I’ll have a better capability to test mountall patches as soon as i can get my system to run *some* version of mountall. ;-)
[12:05] <ion> ti052638 < ion> keybuk: As in, boot using it
[12:05] <Keybuk> oh cool
[12:06] <Keybuk> at a quick glance, isn't there a libudev way of doing this rather than dealing with sysfs by hand?
[12:06] <Keybuk> you have mnt->udev_device ;)
[12:06] <ion> Good point. I’ll take a look at that struct.
[12:06] <Keybuk> http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/
[12:07] <Keybuk> e.g. while (dev = udev_device_get_parent ())
[12:07] <Keybuk>         if (dev is what you're looking for)
[12:07] <Keybuk>             break;
[12:07] <Keybuk> etc.
[12:08] <ion> How about slaves?
[12:22] <ion> udevadm info --export-db doesn’t seem to contain slave information.
[12:23] <Keybuk> you can still get things like that as properties, attributes, etc.
[12:25] <ion> udevadm info --query=all --name=/dev/alku-main/root: http://pastebin.com/f49b5a4b
[12:26] <ion> udevadm info --attribute-walk --name=/dev/alku-main/root: http://pastebin.com/f5c3b19a
[12:26] <ion> I fail to notice any mention of the md slave.
[12:38] <ion> I made made the physical_dev_ids function work on Mount * directly, patch updated. I didn’t implement the udev thing yet. I’ll have to research more.
[12:49] <ion> keybuk: Whoops, forgot to add the entry to the list in queue_fsck. Patch updated.
[13:00] <ion> It would be nice to see whether the actually code works in the current form.
[13:01] <Keybuk> am figuring out why it doesn't now ;)
[13:01] <ion> Hehe
[13:09] <ion> Any debug output?
[13:13] <Keybuk> OMG
[13:13] <Keybuk> IT BUILT
[13:13] <Keybuk> ion: --debug ;)
[13:20] <ion> I mean, when you tested it
[13:22] <Keybuk> ?
[13:23] <ion> You said you’re figuring out why it doesn’t work. Does it print debug output i could take a look at?
[13:27] <Keybuk> oh, I mean mountall in general
[13:29] <ion> Ah
[14:15] <[psy]> so whats is the RightWay(tm) to turn off a service on boot?
[14:17] <[psy]> and: how do i make my ldap-service start automaticly when the user wants to start apache, for example?
[14:17] <[psy]> we wanna rewrite our daemontools based distro to upstart
[14:19] <[psy]> oh and: how do i make everything that 'depends' on ldap, stop, and start again automaticly, when the user wants to restart ldap?
[14:19] <[psy]> (just like gentoo's init system does)
[14:20] <[psy]> i've read the wiki, but i'm not sure how to do it with events.
[14:27] <Keybuk> if you're thinking in terms of "depends", you need to take a few steps backwards
[14:54] <[psy]> right
[14:54]  * [psy] steps back
[14:54] <[psy]> back to daemontools you mean? :)
[14:55] <Keybuk> no, just your way of thinking
[14:55] <Keybuk> Upstart isn't a dependency-based system
[14:55] <[psy]> its event based, right?
[14:55] <Keybuk> if you're interested in Upstart, you need to learn not to think in terms of dependencies
[14:55] <Keybuk> execatly
[14:56] <[psy]> my question was how to do it with events..is it possible?
[14:56] <Keybuk> yes
[14:56] <[psy]> e.g.: user wants to start apache, so ldap is started first
[14:56] <Keybuk> but you're still thinking in terms of dependencies
[14:56] <Keybuk> you need to unlearn that
[14:56] <Keybuk> that's not how Upstart works
[14:56] <[psy]> ok
[14:57] <Keybuk> in Upstart, we would say that apache is started when ldap is started
[14:57] <Keybuk> *not* the other way around
[14:57] <[psy]> so i need to but a start on ldap in the apache event-config
[14:58] <[psy]> however: i dont want apache to be started as soon as ldap is started all the time
[14:58] <[psy]> sometimes i just wanna start ldap, without apache
[14:58] <Keybuk> why?
[14:58] <[psy]> dont think in terms of why
[14:58] <[psy]> ldap+apache is just an example
[14:58] <Keybuk> what are the conditions in which apache would not be started at boot?
[14:59] <Keybuk> we don't do hypothetical examples here, only real world ones
[14:59] <[psy]> ok
[15:00] <[psy]> so i cant have ldap start automaticly as soon as i try to start apache? e.g. in the pre-start script of apache or something?
[15:00] <[psy]> dont tell me i need to unlearn dependencys
[15:01] <[psy]> maybe its time for upstart to implement dependencys 
[15:02] <sadmac2> [psy]: why?
[15:02] <[psy]> why?
[15:03] <sadmac2> yeah, why do you need them?
[15:03] <[psy]> for example: winbindd cant start if smbd isnt running yet
[15:04] <[psy]> currently with daemontools it keeps restarting until smbd is started
[15:04] <[psy]> what i want is a way to start smbd automaticly if winbindd is started
[15:04] <[psy]> and stop winbindd automaticly when smbd is stopped
[15:04] <[psy]> by the sysadmin
[15:04] <sadmac2> ok. upstart does that...
[15:05] <[psy]> how?
[15:05] <sadmac2> have smbd start winbind
[15:06] <[psy]> thats the wrong way around
[15:06] <[psy]> package-maintainer-wise
[15:06] <sadmac2> ok
[15:07] <[psy]> now this will happen: for some reason ldap is started. ldap starts smbd, and smbd starts winbindd
[15:07] <sadmac2> have winbind be started by smbd
[15:07] <sadmac2> yes. that will happen. so?
[15:07] <[psy]> but the sysad doesnt want smbd and winbindd running!
[15:07] <sadmac2> why not?
[15:07] <[psy]> he only wants ldap
[15:08] <[psy]> you wont get peace with that attidue
[15:08] <[psy]> attitude 
[15:08] <sadmac2> its not a rhetorical question
[15:08] <[psy]> i just told you: samba IS installed, but the sysad doesnt need it or use it. however, ldap IS needed for something
[15:09] <sadmac2> so he should uninstall samba
[15:09] <ion> keybuk: Patch updated. Using libudev now. It still needs to be tested, i only know it compiles. :-P
[15:09] <[psy]> furthermore: the package maintainer of openldap doesnt want all kinds of references to smbd in his ldap-event script
[15:09] <sadmac2> [psy]: the references can go in the other scripts
[15:09] <sadmac2> start on starting ldap
[15:10] <[psy]> ah ok
[15:10] <[psy]> well let me ask another question: how do i keep a service down without removeing or moving the event definition?
[15:11] <Keybuk> you'd place the service in manual mode (0.10 era)
[15:11] <sadmac2> [psy]: at the moment you don't. solution coming.
[15:11] <[psy]> oki 
[15:11] <[psy]> i'll wait a while then
[15:12] <[psy]> i dont see any advantages to daemontools at the moment
[15:12] <sadmac2> Keybuk: one more 3-day weekend and event_operator will be gone from my tree :)
[15:12] <[psy]> some new features i dont need, some missing features i do need :)
[15:12] <Keybuk> sadmac2: I know I still have your mail to review :-/
[15:12]  * Keybuk is behind with lots of things atm
[15:13] <[psy]> and you really should implement dependencies
[15:13] <sadmac2> Keybuk: considering that changing event_operator was a precursor to that proposal, the fact that I figured out how to get rid of it entirely is kind of surprising.
[15:13] <[psy]> yeah..you could life without them...but then we you could say: hey..who needs packages, just ./confiugre;make install everything by hand because 'thats how we see it'
[15:14] <sadmac2> [psy]: there are some more powerful relationships coming. I won't say "dependencies" though.
[15:14] <[psy]> oki
[15:19] <[psy]> well the most important thing is the ability for the sysad to shutdown something permanently
[15:20] <[psy]> but we could work around that by using symlinks like /etc/event.d/servicename -> /etc/events/realservicescript
[15:20] <[psy]> sysv init style syslink ;)
[15:20] <[psy]> m
[15:21] <sadmac2> [psy]: that's a good for-now solution. Nicer things are coming.
[15:21] <[psy]> yup
[15:46] <ion> keybuk: Another small update, better debug logging in add_device.
[15:47] <ion> keybuk: The dev_ids code seems to work on a box that has lvm over md over two HDDs. I haven’t managed to test the fsck queue code yet.
[15:50] <ion> keybuk: I still had to call udev_device_get_syspath, add "/slaves" to its result and call udev_device_new_from_syspath for each entry under that path. I didn’t figure out a way to traverse the slaves using plain libudev API.
[15:52] <sadmac2> ion: what is this you're working on?
[15:55] <ion> sadmac: Keybuk implemented mountall, a program that handles the fscking and mounting of fstab entries in the proper order, parallelizing fsck as much as possible. Well, too much, since all fsck instances run in parallel, with a /* FIXME */ for having each fsck instance use a lock for each underlying physical device to avoid thrashing. My patch fixes the FIXME.
[15:58] <sadmac2> ion: oic
[16:26] <ion> keybuk: How does the patch look now?
[16:27] <Keybuk> ion: haven't looked yet ;)
[17:12] <ion> keybuk: I created the file /looptest, made an ext2 filesystem on it and added ‘/looptest /mnt ext2 loop 0 2’ to fstab. Mountall seems to end up waiting forever in the main loop select().
[17:16] <sadmac2> ion: missing an nih_main_loop_interrupt ?
[17:17] <Keybuk> ion: isn't it just waiting for the root filesystem to be ready?
[17:17] <Keybuk> udevadm trigger --subsystem-match=block
[17:18] <ion> http://pastebin.com/f2483aa5a
[17:19] <ion> It says mountpoint_ready: /
[17:20] <ion> Oh, now would be a good idea to test without my patch. :-P
[17:20] <ion> Nope, it still does the same thing.
[17:28] <ion> The same issue with a swapfile: i created the file /swaptest, did mkswap and added ‘swaptest none swap sw 0 0’ to fstab. Mountall says mountpoint_ready: / and then blocks forever in select().
[17:29] <ion> ‘/swaptest none swap sw 0 0’
[17:29] <ion> (having commented out the /looptest entry)
[17:32] <sadmac2> Keybuk: strange thought. What if instead of start on started <name> <env> it was start on started <env>, where the first item in <env> was always UPSTART_EVENT_NAME= ?
[17:32] <Keybuk> sadmac2: ugh
[17:32] <Keybuk> besides, 0.10 that's start on <job> started again ;)
[17:33] <sadmac2> Keybuk: yeah, I was wondering about the semantics for that. Is event.name == job.name and started is an argument?
[17:34] <Keybuk> jobs, states and events are the same fundamental thing
[17:34] <Keybuk> event is just an edge of a state
[17:34] <Keybuk> it's not so much an argument, as a sub-state if that makes sense
[17:34] <sadmac2> the edge of a state is not the same fundamental thing as a state.
[17:34] <Keybuk> I think it is
[17:35] <sadmac2> Keybuk: if you buy an apple and I give you the core of an apple are you happy>
[17:35] <Keybuk> *baffled*
[17:35] <sadmac2> Keybuk: better: if you buy a table and I give you the edge of a table, are you happy?
[17:35] <Keybuk> you're being silly
[17:35] <Keybuk> stop it
[17:37] <sadmac2> Keybuk: what does muddling states and events gain us?
[17:37] <Keybuk> symmetry
[17:38] <sadmac2> Keybuk: why not make states and malloc'd regions the same too then?
[17:38] <Keybuk> you're still being silly
[17:39] <sadmac2> If I'm being silly by following your logic to its conclusion...
[17:39] <Keybuk> for example:
[17:39] <Keybuk> one job
[17:39] <Keybuk>   while network-device eth0 up
[17:39] <Keybuk> another job
[17:39] <Keybuk>   while apache running
[17:39] <Keybuk>   on network-device eth0 up
[17:40] <Keybuk> that's why it makes sense for events and states to be symmetric
[17:40] <Keybuk> it's simple, obvious and elegant
[17:42] <sadmac2> does network-device eth0 up correspond to starting, started, stopping, stopped, or something in the middle?
[17:42] <Keybuk> to whatever you want
[17:44] <sadmac2> and how do you specify which?
[17:46] <sadmac2> Keybuk: I see what you're doing, but I think you describe it poorly. I think this model has no events at all (at least not ones visible to the user)
[17:47] <Keybuk> on is an event
[17:47] <sadmac2> on itself?
[17:48] <Keybuk> no
[17:48] <Keybuk> on matches events
[17:48] <Keybuk> while matches states
[17:48] <Keybuk> states are either true or false
[17:48] <sadmac2> but events are states
[17:48] <sadmac2> or so you say
[17:48] <Keybuk> events do not have any value
[17:48] <Keybuk> events are when states change
[17:49] <sadmac2> so are events the same as states or different?
[17:49] <Keybuk> events occur when states change
[17:50] <sadmac2> ok, so events aren't states
[17:53] <sadmac2> that kind of ruins your explanation of on's arguments
[17:55] <Keybuk> why?
[17:56] <sadmac2> Keybuk: because that explanation began "events are states"
[17:56] <sadmac2> Keybuk: and we've now arrived at "events aren't states"
[17:56] <Keybuk> only the way you describe them
[17:56] <Keybuk> to me they're one and the same thing
[17:57] <sadmac2> Keybuk: then why do we have two words for it?
[17:57] <sadmac2> not a rhetorical question.
[17:57] <Keybuk> because I haven't thought of a better word yet
[17:58] <sadmac2> Keybuk: I could follow you if there were no events at all, just states
[17:58] <Keybuk> I don't like the word "states"
[17:58] <sadmac2> Keybuk: on apache started => start at the earliest point in time at which apache started is true
[17:59] <Keybuk> right
[17:59] <sadmac2> Keybuk: if you're into the true/false thing, "conditions" would be the next point.
[17:59] <Keybuk> I'm not as much of a fan of PhD level logic problems are you are ;)
[17:59] <sadmac2> Keybuk: all of this makes 0.6 compatibility reeeely grody. Are you still interested in 0.6 compatibility?
[17:59] <Keybuk> I don't see it as a problem
[17:59] <sadmac2> Keybuk: I think "conditions" is a fairly sane word
[18:00] <sadmac2> Keybuk: information coded as conditions/states for 0.10 as you describe is coded as environment variables in 0.6. That gets scary fast.
[18:01] <sadmac2> unless these two things don't interact seamlessly
[18:01] <ion> keybuk: What’s missing from the ubuntu-boot PPA so that one could upgrade to it and have a booting system? Perhaps i could do something.
[18:02] <sadmac2> Keybuk: I actually prefer conditions precisely because its /less/ prominent in PhD-land. States is a reeeeely loaded word from the formalist side of things. Especially when we talk about "state machines"
[18:02] <sadmac2> which are rarely what "state machines" really are when we're talking about them.
[18:06] <sadmac2> Keybuk: also I wonder about the usefulness of your example. What wants to start "on network-device"? If it needs the network device to start why doesn't it care if it goes away halfway through initialization?
[18:08] <sadmac2> so if on x means "at the earliest point when x is true," then I'd assume we'd have an after x for "the earliest point when x is false"
[18:08] <sadmac2> from...until would want a from after...until, and a from...through counterpart as well
[18:14] <Keybuk> ion: figuring out why it's not working ;)
[18:14] <Keybuk> it works on one mini
[18:14] <Keybuk> but packaged up it doesn't
[18:14] <Keybuk> trying to figure out what step I've missed
[18:14] <Keybuk> sadmac2: ntpdate is started when a network device comes up
[18:15] <Keybuk> I don't think your "after" case is invalid, I've been thinking the same thing
[18:17] <sadmac2> Keybuk: beyond that, I'd keep the term states. It has heritage in the project and its not really "wrong" just yet. (Events I'd stop saying for awhile. They're still present here, but they're hidden."
[18:27] <sadmac2> honestly I'd be ok with calling them jobs.
[18:27] <sadmac2> that's what the code calls them now (or what will become them)
[18:29] <Keybuk> right, I suspect that's what the code will always call them ;)
[18:31] <sadmac2> Keybuk: so in the phrase "on foo" foo is a state, but on infers an event from it. "after" would take the same state and infer a different event.
[18:31] <Keybuk> don't know
[18:31] <Keybuk> I've used after for temporary events
[18:31] <Keybuk> <time period> after <event>
[18:33] <sadmac2> Keybuk: either way. Point is events don't really have names and arguments anymore. We don't talk about them directly in the config. We mention states, and an event is implied by context.
[18:34] <sadmac2> Keybuk: I'd also imagine initctl emit doesn't make much sense anymore. Things like udev can just start states for their devices.
[18:37] <Keybuk> no it still makes sense I think
[18:37] <Keybuk> there are still events that don't have attached states
[18:37] <Keybuk> events used as commands
[18:38] <sadmac2> Keybuk: how do we talk about them in job definitions. Do we just put them in the same namespace as states so "on fooevent" works too?
[18:47] <Keybuk> that's a pretty good question
[18:47] <Keybuk> I can't find my notes on this
[18:47] <Keybuk> but basically you have events that are really states
[18:47]  * sadmac2 gets nervous
[18:48] <sadmac2> how long do they last?
[18:48] <sadmac2> also you should publish these "notes" :P
[18:48] <Keybuk> I mean in the current scheme
[18:48] <sadmac2> were we all perfect :)
[18:49] <Keybuk> to publish involves typing
[18:49]  * Keybuk writes a lot with pen, paper and whiteboards
[18:49] <Keybuk> so
[18:49] <Keybuk> events that are states
[18:49] <Keybuk> "job started" type things
[18:49] <Keybuk> there are events that are real events that would never have states
[18:49] <Keybuk> control-alt-delete being a good example
[18:50] <Keybuk> and there are events that we use a bit like commands
[18:50] <Keybuk> where the *completion* is important to the emitter
[18:50] <Keybuk> maybe hooks is more appropriate than commands as a description
[18:50] <Keybuk> "I'm going to reboot, does anyone need to do anything first?"
[18:52] <sadmac2> Keybuk: so theres still the question of this time-interval (state) => point-in-time (event) mapping.
[18:53] <sadmac2> For the first case, job started clearly maps to an interval. if we need an event we say "The earliest point at which 'job started'"
[18:53] <sadmac2> for case two... that's hard.
[18:53] <Keybuk> I don't think it's earliest point at which
[18:53] <sadmac2> for case three, that looks a lot like injecting case 1.
[18:53] <Keybuk> it's "after 'job started' has happened"
[18:53] <Keybuk> the key point is that 'job started' may no longer be true anymore
[18:53] <sadmac2> Keybuk: so when the job stops
[18:53] <Keybuk> becoming false doesn't cancel the fact that the event is still queued
[18:54] <sadmac2> Keybuk: I would say job started is a convenience alias for job running
[19:09] <Keybuk> right, so that's the interesting bit
[19:09] <Keybuk> isn't "job running" just "job" ? :)
[19:10] <Keybuk> or is "job" true when the job *should* be running, but "job running" true when the job *is* running
[19:10] <Keybuk> etc.
[19:10] <sadmac2> Keybuk: assuming "job foo" can't be true unless "job" is true, then just job would have to be job starting U job running U job stopping
[19:11] <sadmac2> Keybuk: which means job is true when it should be running
[19:11] <sadmac2> Keybuk: which I like
[19:11] <Keybuk> right
[19:11] <Keybuk> that's pretty much the direction I was thinking
[19:12] <sadmac2> Keybuk: the idea that on tests for presence also gets around the "what if you start on started but its already running when you insert your job" thing.
[19:12] <Keybuk> huh?
[19:13] <sadmac2> Keybuk: suppose I have a running system, where apache is running. If I add a new job and have "on apache started" in it, if on is looking for an event, my job won't be running, because the "apache started" event has already passed. If on checks for earliest point at which a state is true, though, it can figure out to start my job right away.
[19:14] <sadmac2> when I say new job I mean new job and class. Completely new .conf
[19:14] <Keybuk> err
[19:15] <Keybuk> but you don't *want* that to be started
[19:15] <Keybuk> that's the whole point
[19:15] <Keybuk> if you're using "on" it should NOT look-behind like that
[19:15] <Keybuk> your "on apache started" job should only be run *when* apache is started
[19:15] <Keybuk> not if apache happens to be running
[19:15] <sadmac2> yeah. out-moded problem.
[19:15] <Keybuk> this is exactly how it differs from "while" :)
[19:15] <Keybuk> (and that while also implies a stop condition)