/srv/irclogs.ubuntu.com/2008/04/11/#upstart.txt

Keybukhurrah14:06
Keybukafter 4 hours of fiddling, I'm now back to being able to make a change :p14:06
Keybukhttp://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb?start_revid=scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb14:42
Keybuk\o/14:42
Keybukand with the following revision, we now support respawn and task :)14:59
Keybuktask14:59
Keybukexec /some/script14:59
Keybukrespawn14:59
Keybukwill repeat /some/script until it exits with zero :)14:59
ion_keybuk: Nice17:02
KeybukMy main blocker at the moment is deciding whether or not to export the difference between Jobs and Instances over D-Bus17:38
Keybukand if not, which way to err17:38
Keybukie.17:46
Keybukshould it have a D-Bus object per job17:46
Keybukshould it have a D-Bus object per instance17:46
Keybukor should it have D-Bus objects for both?17:46
Keybukper job would mean you had .../jobs/getty with Start() and Stop() methods, and methods to probe for instance and process information17:47
Keybukper instance would mean you had .../jobs/getty-tty1 with a Stop() method; and a Start(name) method on the upstart object17:48
Keybukboth would mean you had .../jobs/getty with Start() and StopAll() methods, then .../jobs/getty/tty1 with a Stop() method and methods to probe process information17:48
ion_I’d lean towards the latter, and .../jobs/getty would provide a method to find a list of .../jobs/getty-tty1 etc.17:48
ion_My thinking tends to favor object-orientation.17:49
Keybukthe only real problem with the latter I guess is the overhead in terms of D-Bus objects17:50
KeybukJob.Start(Array of String env)17:50
Keybukjob.GetInstance(Array of String env)17:50
Keybukjob.GetInstanceByName(String name)17:50
Keybuksomething like that?17:50
ion_But is that overhead really that big?17:51
Keybukmaybe not I guess17:51
KeybukJob.Start(Array of String env) => (Object Path instance)17:51
KeybukJob.GetInstanceByName(String name)17:52
KeybukJob.GetInstanceByEnv(Array of String env)17:52
Keybuk(all => instance)17:52
KeybukJob.StopAll(Array of String env)17:52
KeybukInstance.Stop(Array of String env)17:52
KeybukInstance.Restart()17:52
ion_Looks nice.17:53
KeybukManager.GetJobByName(String name)17:53
KeybukI guess that'd mean I could throw away instance ids :p18:15
KeybukUPSTART_JOB=getty18:15
KeybukUPSTART_INSTANCE=tty118:15
Keybukwould be enough :p18:15
ion_How would that go currently?18:15
Keybukright how you'd have18:16
KeybukUPSTART_JOB=getty18:16
KeybukUPSTART_JOB_ID=372118:16
Keybukwhere initctl would only use the latter18:16
Keybukif I dropped ids, initctl would use both18:16
KeybukManager.GetJobByName($UPSTART_JOB).GetInstanceByName($UPSTART_INSTANCE).Stop() :p18:16
ion_Nice18:17
Keybuk"start" would become an error in a job18:17
Keybukwith "restart" being the right command18:18
Keybukie.18:18
Keybukpre-stop script18:18
Keybuk  [ ... ] || restart18:18
Keybukend script18:18
Keybuk?18:18
Keybukhmm18:18
Keybukmaybe they should still be different18:18
Keybukstart returns you to start without killing18:18
Keybukrestart would kill, but return you back to start again18:18
ion_Any use cases?18:20
Keybukjust thinking of things being common senes18:21
Keybukthere's a few obvious ones18:21
Keybukstop on stopping some-other-job18:21
Keybukpre-stop script18:21
Keybuk  if can-carry-on-with-it-but-need-restart; then18:21
Keybuk    restart18:21
Keybuk  fi18:21
Keybuk  if can-ignore-it-safely; then18:22
Keybuk    start18:22
Keybuk  fi18:22
Keybukend script18:22
ion_Perhaps start should be named otherwise to avoid confusion, though.18:22
Keybuksuch as?18:25
ion_I dunno. cancel-stop? :-P18:29
Keybukion_: that'd mean a /usr/bin/cancel-stop? :p19:35
ion_Well, it would, and that would suck. :-P19:41
Keybukheh19:42

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!