=== 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 | ||
Shred01 | hello all | 06:41 |
---|---|---|
Shred01 | i'm wondering how i can simulate events to test an upstart script i am writing. | 06:41 |
shawarma | Shred01: initctl emit <event> | 08:40 |
shawarma | Shred01: The initctl(8) man page is probably your friend. | 08:40 |
=== 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 | ||
JK44 | hi, here is my question : | 11:16 |
JK44 | in the FAQ, it is said "will upstart replace DBUs " (because of the respawn feature) | 11:17 |
Keybuk | right ... (though it's nothing to do with the respawn feature) | 11:18 |
JK44 | the answer is, "no but your software could directly tell upstart to restart program if they directly notice | 11:18 |
Keybuk | not correct | 11:18 |
JK44 | oh ? | 11:18 |
Keybuk | the question is simply about activation of services, not about respawning them | 11:18 |
JK44 | yes but if dbus that a setrvice is dead it respawn it | 11:19 |
JK44 | 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:20 |
JK44 | well it is another dumb question, if i tell upstart to respawn an active program it does not restart it | 11:23 |
JK44 | so it should be ok | 11:23 |
Keybuk | err | 11:25 |
Keybuk | sorry | 11:25 |
Keybuk | I don't understand your questions | 11:25 |
=== phoenix24 [i=gwukk@ns37986.ovh.net] has joined #upstart | ||
Keybuk | dbus isn't a service manager, so it doesn't respawn services | 11:27 |
Keybuk | it has some code to attempt to activate services in the user's session, but doesn't particularly deal with respawning, etc. | 11:27 |
JK44 | if Dbus receive a message for an inactive service, it launch the defined command line for this service | 11:38 |
JK44 | we use this feature as service respawning | 11:38 |
JK44 | well we dont detect crashes | 11:38 |
Keybuk | yes, it does that | 11:38 |
JK44 | but, its some kind of crash reactivation when needed | 11:39 |
JK44 | i would like to keep using this feature | 11:39 |
JK44 | and also the uspart respawning | 11:39 |
Keybuk | whereas upstart's respawning is based on processes dying | 11:39 |
Keybuk | in the theoretical Upstart+Dbus world, the "defined command line" would be instead "defined upstart service" | 11:39 |
JK44 | so the command line in Dbus could be a call to upstart | 11:39 |
Keybuk | and dbus would send upstart a message to start a particular service | 11:39 |
JK44 | exact | 11:40 |
JK44 | but isn't a risk to have double restarts if the process dying detection and the dbus command line are executed concurrently ? | 11:40 |
JK44 | for exemple : upstart detect a crashh and lose cpu | 11:41 |
JK44 | dbus send his message | 11:41 |
JK44 | the message is received, the service is activate | 11:42 |
Keybuk | dbus would send messages that affect upstart's state machine only | 11:42 |
Keybuk | upstart is very resilient to this kind of thing | 11:42 |
JK44 | ok, so its totaly safe, its a great thing | 11:42 |
JK44 | thk very much | 11:42 |
=== 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 | ||
shawarma | 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:46 |
Keybuk | I don't think it makes sense | 03:51 |
Keybuk | what's your use cas? | 03:51 |
Keybuk | +e | 03:51 |
shawarma | 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:53 |
shawarma | When we want to ditch sysvrc, we need to completely rework each and every init script, I suppose. | 03:54 |
Keybuk | right | 03:54 |
shawarma | I just hadn't really thought a lot about that. | 03:54 |
Keybuk | we need only do them one at a time though | 03:55 |
shawarma | 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:55 |
Keybuk | cherry picking is fine | 03:56 |
shawarma | 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:56 |
Keybuk | you would have to do bottom-up for "dependencies", yes | 03:57 |
Keybuk | but we have very few of those in reality outside of initscripts | 03:57 |
shawarma | True. | 03:58 |
Keybuk | the baz bit doesn't matter, since the runlevel stuff would be run after any upstart stuff | 03:59 |
shawarma | Right. That's why I said we should work our way either up or down the list. Not from the middle and outwards :) | 04:00 |
Keybuk | first thing is to get filesystem mounting converted and bullet-proof | 04:02 |
Keybuk | then the miscellaneous over things to do with block devices, and setting up the machine (hostname, etc.) | 04:02 |
Keybuk | after that, networking | 04:02 |
Keybuk | and then services from the bottom up | 04:02 |
shawarma | Right. That should cover pretty much everything. | 04:03 |
shawarma | 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:05 |
Keybuk | yeah | 04:08 |
Keybuk | indeed | 04:08 |
Keybuk | AGA : Q)EGTT/QFAXX/IV/NBO/A/000/999/5227N00145W005 | 04:08 |
Keybuk | FROM 07/04/30 07:19 TO 07/08/30 23:59 C1947/07 | 04:08 |
Keybuk | E)LARGE NUMBERS OF PIGEONS CROSSING RWY 15/33 ESE TO WNW | 04:08 |
Keybuk | FM THR 15 TO TWY K, SFC TO 100FT AGL, SR-SS. | 04:08 |
Keybuk | ^ rofl | 04:08 |
Keybuk | (momentarily off topic) | 04:08 |
shawarma | *G* | 04:08 |
shawarma | EGTT is Heathrow? | 04:11 |
Keybuk | yes | 04:33 |
Keybuk | ish | 04:33 |
Keybuk | EGTT is the London FIR | 04:34 |
Keybuk | EGLL is Heathrow itself | 04:34 |
Keybuk | that's a NOTAM for EGBB (Birmingham International) | 04:38 |
=== 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 | ||
Shred01 | does upstart in feisty emit events for old-style initscripts? | 12:21 |
Shred01 | i.e. can i write a bona-fide upstart script and have it wait for an old-style initscript to be done starting? | 12:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!