[06:41] <Shred01> hello all
[06:41] <Shred01> i'm wondering how i can simulate events to test an upstart script i am writing.
[08:40] <shawarma> Shred01: initctl emit <event>
[08:40] <shawarma> Shred01: The initctl(8) man page is probably your friend.
[11:16] <JK44> hi, here is my question :
[11:17] <JK44> in the FAQ, it is said "will upstart replace DBUs " (because of the respawn feature)
[11:18] <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:19] <JK44> yes but if dbus that a setrvice is dead it respawn it
[11:20] <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:23] <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:25] <Keybuk> err
[11:25] <Keybuk> sorry
[11:25] <Keybuk> I don't understand your questions
[11:27] <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:38] <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:39] <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:40] <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:41] <JK44> for exemple : upstart detect a crashh and lose cpu
[11:41] <JK44> dbus send his message
[11:42] <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
[03:46] <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:51] <Keybuk> I don't think it makes sense
[03:51] <Keybuk> what's your use cas?
[03:51] <Keybuk> +e
[03:53] <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:54] <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:55] <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:56] <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:57] <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:58] <shawarma> True.
[03:59] <Keybuk> the baz bit doesn't matter, since the runlevel stuff would be run after any upstart stuff
[04:00] <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:02] <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:03] <shawarma> Right. That should cover pretty much everything.
[04:05] <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:08] <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:11] <shawarma> EGTT is Heathrow?
[04:33] <Keybuk> yes
[04:33] <Keybuk> ish
[04:34] <Keybuk> EGTT is the London FIR
[04:34] <Keybuk> EGLL is Heathrow itself
[04:38] <Keybuk> that's a NOTAM for EGBB (Birmingham International)
[12:21] <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?