[16:02] <ion> keybuk: A user thinks mountall’s ionice code doesn’t actually ionice fscks properly on his system. That diagnosis hasn’t been verified by me yet, but could my code be wrong due to me misunderstanding process groups? After fork and before exec(fsck), i do setpgid (0, 0) (the fsck is now supposed to be the leader of a process group with the same id as the pid, right?) and the priority setting is done with ioprio_set (IOPRIO_WHO_PGRP, fsck_pid, ...)
[16:03] <ion> I did that in case some fsck implementation forks children which do the havy IO.
[16:03] <ion> heavy
[16:04] <Keybuk> right
[16:08] <ion> Said user ripping all of upstart, mountall and plymouth out of his system as a reaction doesn’t help with debugging the issue he had. :-D
[16:21] <Stevee> hello Keybuk, is there any way the see the current development state of the next upstart version ? 
[16:22] <Keybuk> nope
[16:22] <Stevee> at launchpad i only can see that "trunk" but there aren't any changes
[16:23] <Stevee> oh, thats bad, what will be the next version ? 0.6.7 or any other release number ?
[16:23] <Keybuk> 0.10.0
[16:23] <Stevee> wow, great
[16:24] <Stevee> what do you think, when it will be released ?
[16:24] <Keybuk> when it's ready
[16:25] <Keybuk> it's a development project at the moment
[16:25] <Keybuk> some very big changes under the hood
[16:25] <Stevee> oh, i see
[16:25] <Keybuk> so I'm still ripping things apart and experimenting
[16:25] <Keybuk> thus it's not in any state I'd be happy to commit to revision control
[16:26] <Stevee> i see, so you aren't able to guess any release date or period
[16:27] <Keybuk> nope, not yet
[16:27] <Stevee> but good to hear, that development still goes on
[16:27] <Keybuk> 0.6 is stable and useful
[16:28] <Stevee> yes of course, we are using it in the current development version of our distribution
[16:28] <Stevee> and it's great - thanks for your great work
[16:29] <Keybuk> 0.10 is going to be simultaneously simpler and more complex ;-)
[16:29] <Keybuk> ie. by simplifying the core design, you can do more complex things with it
[16:30] <Stevee> that sounds great
[16:30] <Stevee> will there also be that kind of support for "profiles" and / or "cron" replacement ( time based events ) implemented ?
[16:31] <Keybuk> yes
[16:31] <Stevee> yes to both ?
[16:31] <Keybuk> yup
[16:31] <Stevee> great, thanks a lot
[16:31] <Keybuk> simpler > the pre-start/post-start etc. stuff is going away
[16:31] <Keybuk> so there's just one process per job
[16:32] <Keybuk> because the same functionality is there (in 0.6!) by just doing:
[16:32] <Keybuk>   start on starting JOB
[16:32] <Keybuk>   script
[16:32] <Stevee> atm it's very difficult to provide some kind of rescue mode, or to manage the services on startup
[16:32] <Keybuk>     ..
[16:32] <Keybuk>   end script
[16:32] <Keybuk> (equivalent to a pre-start script)
[16:32] <Keybuk> so I'm building that on 0.10
[16:33] <Keybuk> and resulting functionality lets you do things like profiles easily
[16:35] <Stevee> will there be any funktion to execute a command on startup a service and on stopping of that service ?
[16:35] <Stevee> for example: atm we have the network.conf and we execute as pre-start script "network start" and on post-stop script "network stop"
[16:37] <Stevee> but as you told, there could be done more complex things, so may we don't need something like that any more ...
[16:39] <Keybuk> yes
[16:39] <Keybuk> you could define network
[16:39] <Keybuk> then
[16:40] <Keybuk> arg, keep hitting return
[16:40] <Keybuk> yes, you could define network then use it's "starting" and "stopped" events to put your scripts/exec lines
[16:40] <Keybuk> you can do all this in one file in 0.10
[16:40] <Keybuk> (at least that's the plan)
[16:41] <Stevee> wow, great plan / job
[16:41] <Stevee> i can't await the next release :D
[16:41] <ion> Nice
[16:42] <Keybuk> I'm still making sure this all works at the moment ;p
[16:42] <ion> :-)
[16:43] <ion> I take it there will be both blocking and non-blocking post-start relation?
[16:44] <ion> blocking for something that polls until the service is ready and non-blocking for something that should be started after the service and all its blocking post-start scripts are done
[16:44] <ion> for instance
[16:44] <Keybuk> yeah, that's the bit I'm still working on getting right
[16:48] <Keybuk> blocking is surprising when you don't want it
[16:48] <Keybuk> but not blocking is surprising when you *do* want it
[16:48] <Keybuk> and it's getting the balance right
[16:48] <ion> yeah
[16:48] <Keybuk> my current experiment is that "on" blocks and "from"/"while" doesn't
[16:48] <Keybuk> but I'm not sure that's right either