[14:06] hurrah [14:06] after 4 hours of fiddling, I'm now back to being able to make a change :p [14:42] http://bazaar.launchpad.net/~keybuk/upstart/trunk/revision/scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb?start_revid=scott%40netsplit.com-20080411134155-1ormw1ojnkh5thqb [14:42] \o/ [14:59] and with the following revision, we now support respawn and task :) [14:59] task [14:59] exec /some/script [14:59] respawn [14:59] will repeat /some/script until it exits with zero :) [17:02] keybuk: Nice [17:38] My main blocker at the moment is deciding whether or not to export the difference between Jobs and Instances over D-Bus [17:38] and if not, which way to err [17:46] ie. [17:46] should it have a D-Bus object per job [17:46] should it have a D-Bus object per instance [17:46] or should it have D-Bus objects for both? [17:47] per job would mean you had .../jobs/getty with Start() and Stop() methods, and methods to probe for instance and process information [17:48] per instance would mean you had .../jobs/getty-tty1 with a Stop() method; and a Start(name) method on the upstart object [17:48] both would mean you had .../jobs/getty with Start() and StopAll() methods, then .../jobs/getty/tty1 with a Stop() method and methods to probe process information [17:48] I’d lean towards the latter, and .../jobs/getty would provide a method to find a list of .../jobs/getty-tty1 etc. [17:49] My thinking tends to favor object-orientation. [17:50] the only real problem with the latter I guess is the overhead in terms of D-Bus objects [17:50] Job.Start(Array of String env) [17:50] job.GetInstance(Array of String env) [17:50] job.GetInstanceByName(String name) [17:50] something like that? [17:51] But is that overhead really that big? [17:51] maybe not I guess [17:51] Job.Start(Array of String env) => (Object Path instance) [17:52] Job.GetInstanceByName(String name) [17:52] Job.GetInstanceByEnv(Array of String env) [17:52] (all => instance) [17:52] Job.StopAll(Array of String env) [17:52] Instance.Stop(Array of String env) [17:52] Instance.Restart() [17:53] Looks nice. [17:53] Manager.GetJobByName(String name) [18:15] I guess that'd mean I could throw away instance ids :p [18:15] UPSTART_JOB=getty [18:15] UPSTART_INSTANCE=tty1 [18:15] would be enough :p [18:15] How would that go currently? [18:16] right how you'd have [18:16] UPSTART_JOB=getty [18:16] UPSTART_JOB_ID=3721 [18:16] where initctl would only use the latter [18:16] if I dropped ids, initctl would use both [18:16] Manager.GetJobByName($UPSTART_JOB).GetInstanceByName($UPSTART_INSTANCE).Stop() :p [18:17] Nice [18:17] "start" would become an error in a job [18:18] with "restart" being the right command [18:18] ie. [18:18] pre-stop script [18:18] [ ... ] || restart [18:18] end script [18:18] ? [18:18] hmm [18:18] maybe they should still be different [18:18] start returns you to start without killing [18:18] restart would kill, but return you back to start again [18:20] Any use cases? [18:21] just thinking of things being common senes [18:21] there's a few obvious ones [18:21] stop on stopping some-other-job [18:21] pre-stop script [18:21] if can-carry-on-with-it-but-need-restart; then [18:21] restart [18:21] fi [18:22] if can-ignore-it-safely; then [18:22] start [18:22] fi [18:22] end script [18:22] Perhaps start should be named otherwise to avoid confusion, though. [18:25] such as? [18:29] I dunno. cancel-stop? :-P [19:35] ion_: that'd mean a /usr/bin/cancel-stop? :p [19:41] Well, it would, and that would suck. :-P [19:42] heh