[05:42] <asmlinkage> do the "start on" and "stop on" commands work in upstart 0.2.7-7 (Edgy's default version)
[05:42] <asmlinkage> I've written one main script that works fine, but a second script that uses start on and stop on to be started and stopped after the main script but upstart never starts or stops it when I start/stop the main daemon
[05:04] <AlexExtreme> hmm, I saw some commits that looked like the new config code should work now. am I right?
[05:05] <Keybuk> yup
[05:06] <Keybuk> you should be able to write a parse_profile.c in the manner of parse_job.c
[05:06] <Keybuk> and add bits to the enums/switches in conf.h/conf.c
[05:07] <AlexExtreme> hmm
[05:07] <AlexExtreme> i tested it when I saw those commits this morning and it didn't work, some assert failed messages that were going past so fast that I couldn't read them
[05:08] <AlexExtreme> a clean checkout from main, that is
[05:08] <Keybuk> which revno?
[05:10] <AlexExtreme> 720
[05:11] <Keybuk> hmm
[05:11] <Keybuk> "make check" failed?
[05:13] <AlexExtreme> hmm
[05:13] <AlexExtreme> works fine
[05:13] <AlexExtreme> let me try again
[05:15] <Keybuk> could be insufficient testing ;)
[05:15] <AlexExtreme> yikes, i cd'd up one dir too far before doing rm -rf upstart ><
[05:15] <AlexExtreme> oh well
[05:17] <Keybuk> oh yeah
[05:17] <Keybuk> it does kinda break, doesn't it
[05:17] <AlexExtreme> yep ;)
[05:17] <JK455> hi
[05:18] <JK455> i have a dumb newbie question about upstart 
[05:18] <Keybuk> hi
[05:18] <Keybuk> sure
[05:18] <JK455> thx 
[05:18] <JK455> how do i use it for an ordered shutdown 
[05:19] <Keybuk> so an ordered shutdown is an interesting thing
[05:19] <Keybuk> in fact, shutdown in general is interesting
[05:19] <Keybuk> at the minimum, you're going to have an emitted event that indicates you want to shutdown
[05:19] <Keybuk> the compat/sysv uses "runlevel 0" and "runlevel 6" for this
[05:19] <Keybuk> you might use those, or call it "shutdown"
[05:19] <JK455> ok, 
[05:19] <Keybuk> you'd then have some jobs that have "start on shutdown"
[05:19] <JK455> can it be dbus event ?
[05:20] <Keybuk> dbus => not right now, a dbus proxy is planned
[05:20] <Keybuk> (but not yet implemented)
[05:20] <Keybuk> one of the shutdown jobs can order a sequence of other jobs
[05:20] <Keybuk> e.g. you might just have a shutdown job that does the sequence
[05:21] <JK455> am not sure to understand :
[05:21] <JK455> you mean, having an event on all setted process for shutdown
[05:22] <Keybuk> no, just an emitted event
[05:22] <Keybuk> I'm not sure what you mean by setted process ?
[05:22] <JK455> for exemple, in my script i put that it have to stop on that event
[05:23] <Keybuk> right
[05:23] <JK455> like : stop on "shutd_event"
[05:23] <JK455> ok
[05:24] <Keybuk> yeah, that can stop running services
[05:24] <JK455> and i will respect all previously marked dependencies ?
[05:24] <Keybuk> AlexExtreme: that's actually an extremely good way to do it
[05:24] <Keybuk> since the shutdown script won't actually run until the jobs have stopped
[05:24] <JK455> i think not, right ?
[05:24] <Keybuk> JK455: upstart has no concept of dependencies
[05:24] <AlexExtreme> yeah, since the actual shutdown job's script will block until the jobs are stopped
[05:25] <Keybuk> AlexExtreme: *ahem* http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh?start_revid=scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh
[05:25] <AlexExtreme> hmm, is there an echo here? :p
[05:25] <JK455> ok, i have to wrote all events for repect of my own dependencies
[05:25] <AlexExtreme> ah, cool. that fixes it?
[05:25] <Keybuk> AlexExtreme: yeah, stupid mistake
[05:25] <AlexExtreme> k, i'll try it
[05:27] <JK455> and i were to wrote the piece of code that receives dbus message and use them as event, were would i had to start ?
[05:27] <JK455> "if i were"
[05:27] <Keybuk> JK455: how do you mean?
[05:27] <JK455> i would like to receive events by sending dbus messages to upstart
[05:28] <JK455> if i want to do that, do you have any tips for me ?
[05:30] <JK455> well, in fact, maybe i dont need that
[05:39] <AlexExtreme> brb, testing that fix
[05:40] <Keybuk> JK455: you'd need something linked with libdbus to receive the messages/events
[05:40] <Keybuk> and linked to libupstart to pass them on to upstart
[05:40] <Keybuk> (you can do the reverse too, the same way)
[05:40] <Keybuk> libupstart is in the upstart source code in the upstart directory
[05:40] <JK455> ok
[05:40] <Keybuk> util/initctl,c links to it to do everything
[05:41] <Keybuk> fundamentally, you'd match certain dbus messages and use UPSTART_EVENT_EMIT to send them on to upstart
[05:41] <Keybuk> and listen for UPSTART_EVENT messages from upstart, and send them across dbus
[05:41] <JK455> ok, great
[05:42] <JK455> maybe i will wrote it i we decide using it
[05:42] <JK455> thanks a lot for this informations
[05:43] <AlexExtreme> Keybuk: works fine now
[05:43] <AlexExtreme> (mental note: it helps to bzr pull *before* trying)
[05:49] <Keybuk> heh
[07:40] <Keybuk> woo
[07:40] <Keybuk> Keybuk 1 - Config code 0
[07:40] <ion_> \/
[07:42] <Keybuk> I now just have to write the tests for init.conf
[07:56] <AlexExtreme> so init.conf is now possible to implement?
[07:56] <AlexExtreme> uhh
[07:56] <AlexExtreme> so it's now possible to have an init.conf, is what i meant
[09:04] <Keybuk> AlexExtreme: in theory, yup
[09:05] <AlexExtreme> nice
[09:12] <AlexExtreme> hmm
[09:12] <AlexExtreme> some debian guy has sent something to upstart-devel about this meta initscript stuff
[11:39] <Keybuk> AlexExtreme: yeah was just talking to him on #debian-devel
[11:39] <Keybuk> well
[11:39] <Keybuk> ubuntu-devel
[11:39] <Keybuk> and not just
[11:39] <Keybuk> before doctor who, the f word, etc.
[11:41] <Keybuk> AlexExtreme: so the plan there is to have
[11:41] <Keybuk> /etc/init/init.conf (optional configuration file, overrides:
[11:42] <Keybuk> /etc/init/conf.d (directory of configuration files, overrides:
[11:42] <Keybuk> /etc/init/jobs.d (directory of job definitions)
[11:42] <Keybuk> config files can define jobs
[11:42] <Keybuk> e.g.
[11:42] <Keybuk> /etc/init/conf.d/some-random-conf could contain
[11:42] <Keybuk>   job foo
[11:42] <Keybuk>     exec /sbin/daemon -d
[11:42] <Keybuk>     respawn
[11:42] <Keybuk>   end job
[11:42] <Keybuk> which is equivalent (but higher priority than) the same text in /etc/init/jobs.d/foo
[11:43] <Keybuk> conf.d becomes useful when we can define profiles, states, etc.
[11:44] <Keybuk> in general, I expect distros to not use init.conf at all (useful for single-parse embedded systems)
[11:44] <Keybuk> to use conf.d rarely for complicated inter-twining defaults, and setting other configuration things that we define
[11:44] <Keybuk> and largely use jobs.d
[11:50] <Keybuk> (conf.d may make some more sense than states.d though, since you could just have an /etc/init/conf.d/udev that defined states for add->remove of all devices udev emits events for)