=== wasabi_ [n=wasabi@cpe-76-184-122-13.tx.res.rr.com] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === wasabi_ [n=wasabi@cpe-76-184-122-13.tx.res.rr.com] has joined #upstart === asmlinkage [n=toby@c-69-142-94-59.hsd1.pa.comcast.net] has joined #upstart [05:42] do the "start on" and "stop on" commands work in upstart 0.2.7-7 (Edgy's default version) [05:42] 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 === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === sadleder [n=sadleder@p50810FCD.dip0.t-ipconnect.de] has joined #upstart === sadleder [n=sadleder@p50810FCD.dip0.t-ipconnect.de] has left #upstart [] === juergbi [n=juerg@80-219-16-162.dclient.hispeed.ch] has joined #upstart === sadleder [n=sadleder@p50810FCD.dip0.t-ipconnect.de] has joined #upstart === sadleder [n=sadleder@p50810FCD.dip0.t-ipconnect.de] has left #upstart [] === tale [n=tale@207.235.54.1] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart [05:04] hmm, I saw some commits that looked like the new config code should work now. am I right? === phoenix24 [i=mbiodxp@rl259.1blu.de] has joined #upstart [05:05] yup [05:06] you should be able to write a parse_profile.c in the manner of parse_job.c [05:06] and add bits to the enums/switches in conf.h/conf.c [05:07] hmm [05:07] 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] a clean checkout from main, that is [05:08] which revno? [05:10] 720 [05:11] hmm [05:11] "make check" failed? === AlexExtreme runs it [05:13] hmm [05:13] works fine [05:13] let me try again [05:15] could be insufficient testing ;) [05:15] yikes, i cd'd up one dir too far before doing rm -rf upstart >< [05:15] oh well [05:17] oh yeah [05:17] it does kinda break, doesn't it [05:17] yep ;) === JK455 [n=laugeai@fe2adsl-2.wyplay.net] has joined #upstart [05:17] hi [05:18] i have a dumb newbie question about upstart [05:18] hi [05:18] sure [05:18] thx [05:18] how do i use it for an ordered shutdown [05:19] so an ordered shutdown is an interesting thing [05:19] in fact, shutdown in general is interesting [05:19] at the minimum, you're going to have an emitted event that indicates you want to shutdown [05:19] the compat/sysv uses "runlevel 0" and "runlevel 6" for this [05:19] you might use those, or call it "shutdown" [05:19] ok, [05:19] you'd then have some jobs that have "start on shutdown" [05:19] can it be dbus event ? [05:20] dbus => not right now, a dbus proxy is planned [05:20] (but not yet implemented) === phoenix24 [i=qcuotw@rl259.1blu.de] has joined #upstart [05:20] one of the shutdown jobs can order a sequence of other jobs [05:20] e.g. you might just have a shutdown job that does the sequence [05:21] am not sure to understand : [05:21] you mean, having an event on all setted process for shutdown [05:22] no, just an emitted event [05:22] I'm not sure what you mean by setted process ? [05:22] for exemple, in my script i put that it have to stop on that event [05:23] right [05:23] like : stop on "shutd_event" [05:23] ok [05:24] yeah, that can stop running services === AlexExtreme has a "shutdown" job that starts on the runlevel 0 or runlevel 6 event, and then all the other jobs that i want to stop on shutdown have "stop on starting shutdown" [05:24] and i will respect all previously marked dependencies ? [05:24] AlexExtreme: that's actually an extremely good way to do it [05:24] since the shutdown script won't actually run until the jobs have stopped [05:24] i think not, right ? [05:24] JK455: upstart has no concept of dependencies [05:24] yeah, since the actual shutdown job's script will block until the jobs are stopped [05:25] AlexExtreme: *ahem* http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh?start_revid=scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh [05:25] hmm, is there an echo here? :p [05:25] ok, i have to wrote all events for repect of my own dependencies [05:25] ah, cool. that fixes it? [05:25] AlexExtreme: yeah, stupid mistake [05:25] k, i'll try it [05:27] 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] "if i were" [05:27] JK455: how do you mean? [05:27] i would like to receive events by sending dbus messages to upstart [05:28] if i want to do that, do you have any tips for me ? [05:30] well, in fact, maybe i dont need that === phoenix24 [i=ikboo@rl259.1blu.de] has joined #upstart [05:39] brb, testing that fix [05:40] JK455: you'd need something linked with libdbus to receive the messages/events [05:40] and linked to libupstart to pass them on to upstart [05:40] (you can do the reverse too, the same way) [05:40] libupstart is in the upstart source code in the upstart directory [05:40] ok [05:40] util/initctl,c links to it to do everything [05:41] fundamentally, you'd match certain dbus messages and use UPSTART_EVENT_EMIT to send them on to upstart [05:41] and listen for UPSTART_EVENT messages from upstart, and send them across dbus [05:41] ok, great [05:42] maybe i will wrote it i we decide using it [05:42] thanks a lot for this informations [05:43] Keybuk: works fine now [05:43] (mental note: it helps to bzr pull *before* trying) [05:49] heh === phoenix24 [i=dqvvqip@rl259.1blu.de] has joined #upstart === mbiebl [n=michael@e180068066.adsl.alicedsl.de] has joined #upstart === Dalios`` [n=hmmm@216.40.38.230] has joined #upstart [07:40] woo [07:40] Keybuk 1 - Config code 0 [07:40] \/ [07:42] I now just have to write the tests for init.conf [07:56] so init.conf is now possible to implement? [07:56] uhh [07:56] so it's now possible to have an init.conf, is what i meant === Md [i=md@freenode/staff/md] has joined #upstart [09:04] AlexExtreme: in theory, yup [09:05] nice [09:12] hmm [09:12] some debian guy has sent something to upstart-devel about this meta initscript stuff === phoenix24 [i=tlyvk@rl259.1blu.de] has joined #upstart === phoenix24 [i=pyh@rl259.1blu.de] has joined #upstart === mbiebl [n=michael@e180068066.adsl.alicedsl.de] has joined #upstart === phoenix24 [i=dgincl@rl259.1blu.de] has joined #upstart === phoenix24 [i=ksju@rl259.1blu.de] has joined #upstart [11:39] AlexExtreme: yeah was just talking to him on #debian-devel [11:39] well [11:39] ubuntu-devel [11:39] and not just [11:39] before doctor who, the f word, etc. [11:41] AlexExtreme: so the plan there is to have [11:41] /etc/init/init.conf (optional configuration file, overrides: [11:42] /etc/init/conf.d (directory of configuration files, overrides: [11:42] /etc/init/jobs.d (directory of job definitions) [11:42] config files can define jobs [11:42] e.g. [11:42] /etc/init/conf.d/some-random-conf could contain [11:42] job foo [11:42] exec /sbin/daemon -d [11:42] respawn [11:42] end job [11:42] which is equivalent (but higher priority than) the same text in /etc/init/jobs.d/foo [11:43] conf.d becomes useful when we can define profiles, states, etc. [11:44] in general, I expect distros to not use init.conf at all (useful for single-parse embedded systems) [11:44] to use conf.d rarely for complicated inter-twining defaults, and setting other configuration things that we define [11:44] and largely use jobs.d [11:50] (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)