[00:45] Keybuk: just sent an email to our dbus maintainer to get those patches in rawhide [00:47] who's that? [00:47] David Zeuthen [00:58] lol [00:58] I'll nag him tomorrow ;) [00:59] very nice [00:59] He's in westford too :) [01:00] I'll have to bring one of those paper fans. === Amaranth_ is now known as Amaranth === Keybuk_ is now known as Keybuk === Keybuk_ is now known as Keybuk [15:01] Keybuk: good morning [15:19] afternoon [15:20] well, you're closer to GMT, so we'll use your clock === sadmac2_ is now known as sadmac2 [16:22] restarting dbus on a running system = epic fail [16:23] yes [16:23] 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] s/(?:restarting | on a running system)//g [16:24] ion_: ORLY? [16:24] YA [16:39] Keybuk: the test case make targets don't seem to run the dbus code generator as a dependency [16:41] 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] Keybuk: and yes, your patches seem to fix things. [16:46] your dbus patches that is [18:35] Keybuk: wb. Just added another patch to my branch [18:35] rearranged some conditional logic in job_class_reconsider [20:55] 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] 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] EvanR: what platform? [21:27] linux [21:28] EvanR: what distro rather [21:28] its mostly blfs [21:28] with upstart it will be a lot less like blfs [21:29] i am about to start moving all the stuff in /etc/rc.d/init.d to event.d scripts [21:30] is there a best practice for printing out status messages like that ? [21:30] or is it all automatic [21:32] no practice for printing out messages from job defs [21:32] 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] does upstart do things in sequential order, or is multi-thread-like stuff going to affect the messages ordering [21:34] 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] i have the example jobs which do rc* compatability [21:35] yes. those will use your /etc/rc script to run the sysv jobs. [21:37] 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] like... x-mode text-mode single-user mode events or something [21:39] upstart does not, by default, use runlevels [21:39] is the concept of runlevels a purely sysv init thing or what [21:40] the replacement for them is kind of up in the air with 0.3.9 [21:40] 0.5 should see some better mechanisms to deal with different modes. [21:40] does it take a specific kernel parameter as input [21:41] how would i get to single user mode in emergency [21:41] 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] ok so theres no standard [21:41] 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] that would do it. [21:42] what does ubuntu do at the moment [21:42] I believe ubuntu is still largely in sysv-compatible mode. [21:43] though theres a couple community projects that make it use more of upstart's functionality [21:43] 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] echo from within the scripts has worked for me. I don't know why you would have issues. [21:44] ok ill try to get deeper into what is going wrong [22:42] 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] /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] perhaps i should have smbd and nmbd in two separate jobs [22:48] EvanR: you need the "respawn" or "service" stanza in your job definition. [22:48] and you don't want any of your services to daemonize [22:48] so --nodaemons all around [22:49] ok so i should do [22:49] /usr/sbin/smbd -F & [22:49] no & [22:49] if you use respawn, then start won't hang [22:49] i would rather have these two servers controlled by one job [22:49] No. They should be separate [22:49] hmmmm [22:50] so i have jobs smbd and nmbd, i would like to be able to say # start samba, stop samba [22:50] # start smbd [22:51] (nmbd then figures out it needs to be running and runs) [22:51] ok [22:51] respawn doesnt sound right [22:52] you'll just add a "start on started smbd" line to the start of the nmbd job [22:52] respawn means if it crashes upstart will bring it back. If you don't want that, then use "service" in stead. [22:53] oh, service and respawn are mututally exclusive? [22:53] respawn implies service [22:54] and actually, your job definition script should end in an exec [22:54] so "exec /usr/sbin/smbd -F" [22:54] i have that [22:54] and for nmbd [22:54] right [22:54] well service before that [22:55] and "start on started smbd" "exec /usr/sbin/nmbd -F" [22:55] right [22:57] 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] like when? [22:57] ...........dunno [22:58] :P [22:58] i cant think of a reason [22:58] 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] to disable services at bootup, one would comment out the 'start on' stuff... [22:58] hi! [22:58] yes [22:59] heh [23:00] 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] not really important, but I saw it while searching for infos about upstart [23:01] Yes it was :) [23:01] * sadmac2 pats himself on the back [23:05] 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] my dbus sysvinit stop script is testing the exit status of the killed daemon to determine whether it should remove a file [23:24] is that possible to do from the post-stop script