[00:45] <sadmac> Keybuk: just sent an email to our dbus maintainer to get those patches in rawhide
[00:47] <Keybuk> who's that?
[00:47] <sadmac> David Zeuthen
[00:58] <Keybuk> lol
[00:58] <Keybuk> I'll nag him tomorrow ;)
[00:59] <sadmac> very nice
[00:59] <sadmac> He's in westford too :)
[01:00] <sadmac> I'll have to bring one of those paper fans.
[15:01] <sadmac2> Keybuk: good morning
[15:19] <Keybuk> afternoon
[15:20] <sadmac2> well, you're closer to GMT, so we'll use your clock
[16:22] <sadmac2> restarting dbus on a running system = epic fail
[16:23] <Keybuk> yes
[16:23] <sadmac2> Keybuk: that reminds me, if I SIGTERM or otherwise force upstart to re-exec, will it transfer job state to the new instance?
[16:24] <ion_> s/(?:restarting | on a running system)//g
[16:24] <sadmac2> ion_: ORLY?
[16:24] <ion_> YA
[16:39] <sadmac2> Keybuk: the test case make targets don't seem to run the dbus code generator as a dependency
[16:41] <suihkulokki> sadmac2: dbus should do that.. dammit if it is possible to transfer the irc server connections when upgrading irssi, bloody well something as critical as dbus should do that as well
[16:46] <sadmac2> Keybuk: and yes, your patches seem to fix things.
[16:46] <sadmac2> your dbus patches that is
[18:35] <sadmac2> Keybuk: wb. Just added another patch to my branch
[18:35] <sadmac2> rearranged some conditional logic in job_class_reconsider
[20:55] <sadmac2> Keybuk: I see the foo ? TRUE : FALSE; construct in a lot of places. Is Upstart code so sensitive to precise values of TRUE that this is necessary?
[21:27] <EvanR> hey i just got upstart working on my system, many services are started using the existing sysv scripts... however my scripts print messages during startup like 'samba started.... [OK]', and these get messed up with upstart
[21:27] <sadmac2> EvanR: what platform?
[21:27] <EvanR> linux
[21:28] <sadmac2> EvanR: what distro rather
[21:28] <EvanR> its mostly blfs
[21:28] <EvanR> with upstart it will be a lot less like blfs
[21:29] <EvanR> i am about to start moving all the stuff in /etc/rc.d/init.d to event.d scripts
[21:30] <EvanR> is there a best practice for printing out status messages like that ?
[21:30] <EvanR> or is it all automatic
[21:32] <sadmac2> no practice for printing out messages from job defs
[21:32] <sadmac2> dunno why the ones in init.d wouldn't work right. something to do with the FD upstart is passing to the job
[21:33] <EvanR> does upstart do things in sequential order, or is multi-thread-like stuff going to affect the messages ordering
[21:34] <sadmac2> upstart is paralell, but when it is emulating sysv (at least, with the standard jobset which does this) it runs the sysv jobs in serial
[21:35] <EvanR> i have the example jobs which do rc* compatability
[21:35] <sadmac2> yes. those will use your /etc/rc script to run the sysv jobs.
[21:37] <EvanR> lets say that i convert all my stuff to event.d ... is there a common / best / popular way to implement the runs levels, or is the recommended strategy something different in the upstart worl
[21:37] <EvanR> like... x-mode text-mode single-user mode events or something
[21:39] <sadmac2> upstart does not, by default, use runlevels
[21:39] <EvanR> is the concept of runlevels a purely sysv init thing or what
[21:40] <sadmac2> the replacement for them is kind of up in the air with 0.3.9
[21:40] <sadmac2> 0.5 should see some better mechanisms to deal with different modes.
[21:40] <EvanR> does it take a specific kernel parameter as input
[21:41] <EvanR> how would i get to single user mode in emergency
[21:41] <sadmac2> Kernel parameters can be gotten at any time from anywhere by reading and parsing a certain proc file. you can do it yourself in a shell script with sed
[21:41] <EvanR> ok so theres no standard
[21:41] <sadmac2> you can have a single job starting on startup that parses kernel parameters from /proc and then triggers another event depending on the result
[21:41] <sadmac2> that would do it.
[21:42] <EvanR> what does ubuntu do at the moment
[21:42] <sadmac2> I believe ubuntu is still largely in sysv-compatible mode.
[21:43] <sadmac2> though theres a couple community projects that make it use more of upstart's functionality
[21:43] <EvanR> so back to the issue of bootup status messages, you say its all parallel, whats a good strategy to get those message shown
[21:44] <sadmac2> echo from within the scripts has worked for me. I don't know why you would have issues.
[21:44] <EvanR> ok ill try to get deeper into what is going wrong
[22:42] <EvanR> trying to write a job for samba. script /usr/sbin/smbd; /usr/sbin/nmbd; end script starts, but immediately stops (leaving the daemons running). what am i doing wrong
[22:43] <EvanR> /usr/sbin/smbd -D; /usr/sbin/nmbd -F; leaves the job running but sort of hangs the start command, and then stop kills nmbd but not smbd
[22:47] <EvanR> perhaps i should have smbd and nmbd in two separate jobs
[22:48] <sadmac2> EvanR: you need the "respawn" or "service" stanza in your job definition.
[22:48] <sadmac2> and you don't want any of your services to daemonize
[22:48] <sadmac2> so --nodaemons all around
[22:49] <EvanR> ok so i should do
[22:49] <EvanR> /usr/sbin/smbd -F &
[22:49] <sadmac2> no &
[22:49] <sadmac2> if you use respawn, then start won't hang
[22:49] <EvanR> i would rather have these two servers controlled by one job
[22:49] <sadmac2> No. They should be separate
[22:49] <EvanR> hmmmm
[22:50] <EvanR> so i have jobs smbd and nmbd, i would like to be able to say # start samba, stop samba
[22:50] <sadmac2> # start smbd
[22:51] <sadmac2> (nmbd then figures out it needs to be running and runs)
[22:51] <EvanR> ok
[22:51] <EvanR> respawn doesnt sound right
[22:52] <sadmac2> you'll just add a "start on started smbd" line to the start of the nmbd job
[22:52] <sadmac2> respawn means if it crashes upstart will bring it back. If you don't want that, then use "service" in stead.
[22:53] <EvanR> oh, service and respawn are mututally exclusive?
[22:53] <sadmac2> respawn implies service
[22:54] <sadmac2> and actually, your job definition script should end in an exec
[22:54] <sadmac2> so "exec /usr/sbin/smbd -F"
[22:54] <EvanR> i have that
[22:54] <EvanR> and for nmbd
[22:54] <sadmac2> right
[22:54] <EvanR> well service before that
[22:55] <EvanR> and "start on started smbd" "exec /usr/sbin/nmbd -F"
[22:55] <sadmac2> right
[22:57] <EvanR> the start on stuff makes things automatic, but what if i want to start jobs conditionally, given what happens in the script of another job
[22:57] <sadmac2> like when?
[22:57] <EvanR> ...........dunno
[22:58] <EvanR> :P
[22:58] <EvanR> i cant think of a reason
[22:58] <sadmac2> If there's no use case, there's probably no way to do it. If a use case appears, we'll probably think of a way to do it :P
[22:58] <EvanR> to disable services at bootup, one would comment out the 'start on' stuff...
[22:58] <bochecha> hi!
[22:58] <sadmac2> yes
[22:59] <EvanR> heh
[23:00] <bochecha> just came to point a typo on the upstart main site: in the "know users" section, it's written "Fedora Rawhide". It should be "Fedora 9 and above" as Fedora 9 was released :)
[23:01] <bochecha> not really important, but I saw it while searching for infos about upstart
[23:01] <sadmac2> Yes it was :)
[23:01]  * sadmac2 pats himself on the back
[23:05] <bochecha> Anyway, upstart seems like a great project. Keep up the good work!
[23:06]  * bochecha goes back to read some doc to understand better how it works
[23:24] <EvanR> my dbus sysvinit stop script is testing the exit status of the killed daemon to determine whether it should remove a file
[23:24] <EvanR> is that possible to do from the post-stop script