=== Starting logfile irclogs/upstart.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #upstart === Topic for #upstart: Upstart 0.3.8 | http://upstart.ubuntu.com/ | http://upstart.ubuntu.com/wiki/UpstartOnGentoo === Topic (#upstart): set by Md at Sun May 6 19:59:46 2007 === Shred01 [n=brian@d38-139-100.home1.cgocable.net] has joined #upstart [06:41] hello all [06:41] i'm wondering how i can simulate events to test an upstart script i am writing. [08:40] Shred01: initctl emit [08:40] Shred01: The initctl(8) man page is probably your friend. === sadlede1 [n=sadleder@p50814338.dip0.t-ipconnect.de] has joined #upstart === sadlede1 [n=sadleder@p50814338.dip0.t-ipconnect.de] has left #upstart [] === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === termitor [n=proutage@sab57-2-82-236-243-8.fbx.proxad.net] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === JK44 [n=laugeai@fe2adsl-2.wyplay.net] has joined #upstart === juergbi [n=juerg@80-219-19-183.dclient.hispeed.ch] has joined #upstart [11:16] hi, here is my question : [11:17] in the FAQ, it is said "will upstart replace DBUs " (because of the respawn feature) [11:18] right ... (though it's nothing to do with the respawn feature) [11:18] the answer is, "no but your software could directly tell upstart to restart program if they directly notice [11:18] not correct [11:18] oh ? [11:18] the question is simply about activation of services, not about respawning them [11:19] yes but if dbus that a setrvice is dead it respawn it [11:20] so if i set upstart to respawn, and i use dbus to tell upstart to respawn (with command line) will it respawn soft twice [11:23] well it is another dumb question, if i tell upstart to respawn an active program it does not restart it [11:23] so it should be ok [11:25] err [11:25] sorry [11:25] I don't understand your questions === phoenix24 [i=gwukk@ns37986.ovh.net] has joined #upstart [11:27] dbus isn't a service manager, so it doesn't respawn services [11:27] it has some code to attempt to activate services in the user's session, but doesn't particularly deal with respawning, etc. [11:38] if Dbus receive a message for an inactive service, it launch the defined command line for this service [11:38] we use this feature as service respawning [11:38] well we dont detect crashes [11:38] yes, it does that [11:39] but, its some kind of crash reactivation when needed [11:39] i would like to keep using this feature [11:39] and also the uspart respawning [11:39] whereas upstart's respawning is based on processes dying [11:39] in the theoretical Upstart+Dbus world, the "defined command line" would be instead "defined upstart service" [11:39] so the command line in Dbus could be a call to upstart [11:39] and dbus would send upstart a message to start a particular service [11:40] exact [11:40] but isn't a risk to have double restarts if the process dying detection and the dbus command line are executed concurrently ? [11:41] for exemple : upstart detect a crashh and lose cpu [11:41] dbus send his message [11:42] the message is received, the service is activate [11:42] dbus would send messages that affect upstart's state machine only [11:42] upstart is very resilient to this kind of thing [11:42] ok, so its totaly safe, its a great thing [11:42] thk very much === Md [i=md@freenode/staff/md] has joined #upstart === phoenix24 [i=grutu@ns37986.ovh.net] has joined #upstart === jonibo [n=jonas@213.212.2.165] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === phoenix24 [i=qqkcjx@ns37986.ovh.net] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === tale [n=tale@207.235.54.1] has joined #upstart [03:46] Does it make sense at all to use upstart to call a regular init script for starting an stopping stuff or is it really only geared towards actual process supervision? [03:51] I don't think it makes sense [03:51] what's your use cas? [03:51] +e [03:53] I'm just packaging some new stuff, and was about to install the symlinks in rc?.d, and thought how upstart was supposed to take over the world in this case. [03:54] When we want to ditch sysvrc, we need to completely rework each and every init script, I suppose. [03:54] right [03:54] I just hadn't really thought a lot about that. [03:55] we need only do them one at a time though [03:55] Well.. Yes, if we start with the low or high numbers and work our way up or down. We can't just cherry pick them? [03:56] cherry picking is fine [03:56] If something used to be S30foo and is dependent on bar (S20bar) and baz (S40baz) is dependent on foo, how would we do foo in isolation? [03:57] you would have to do bottom-up for "dependencies", yes [03:57] but we have very few of those in reality outside of initscripts [03:58] True. [03:59] the baz bit doesn't matter, since the runlevel stuff would be run after any upstart stuff [04:00] Right. That's why I said we should work our way either up or down the list. Not from the middle and outwards :) [04:02] first thing is to get filesystem mounting converted and bullet-proof [04:02] then the miscellaneous over things to do with block devices, and setting up the machine (hostname, etc.) [04:02] after that, networking [04:02] and then services from the bottom up [04:03] Right. That should cover pretty much everything. [04:05] I have a hunch that it just sounds daunting, but when we actually start doing it, it's not that bad. Most init scripts are already split into a lets-prepare-everything bit and a actually-start-the-bugger bit (and possibly lets-clean-up-the-mess-after-this bit) [04:08] yeah [04:08] indeed [04:08] AGA : Q)EGTT/QFAXX/IV/NBO/A/000/999/5227N00145W005 [04:08] FROM 07/04/30 07:19 TO 07/08/30 23:59 C1947/07 [04:08] E)LARGE NUMBERS OF PIGEONS CROSSING RWY 15/33 ESE TO WNW [04:08] FM THR 15 TO TWY K, SFC TO 100FT AGL, SR-SS. [04:08] ^ rofl [04:08] (momentarily off topic) [04:08] *G* [04:11] EGTT is Heathrow? [04:33] yes [04:33] ish [04:34] EGTT is the London FIR [04:34] EGLL is Heathrow itself [04:38] that's a NOTAM for EGBB (Birmingham International) === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === rawler [n=ulrik@c-cc4fe155.98-2-64736c13.cust.bredbandsbolaget.se] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === rawler [n=ulrik@c-cc4fe155.98-2-64736c13.cust.bredbandsbolaget.se] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === mbiebl [n=michael@e180067242.adsl.alicedsl.de] has joined #upstart === wide-eye [n=jwf@adsl-75-30-242-250.dsl.pltn13.sbcglobal.net] has joined #upstart [12:21] does upstart in feisty emit events for old-style initscripts? [12:21] i.e. can i write a bona-fide upstart script and have it wait for an old-style initscript to be done starting?