=== robbiew is now known as robbiew_ === oojah_ is now known as oojah === robbiew_ is now known as robbiew [16:39] Hello? [16:39] Hello [16:39] Does anyone mind if I ask a few questions about Upstart's scope? [16:39] sure [16:40] ask away [16:40] I'm trying to work out where the init scripts in /etc/init.d fit into things. [16:40] they're supported for compatibility with the LSB, and also to make migration easier for distributions [16:40] the usual way it works is that you run the old "rc" script as an Upstart job [16:40] just as the old sysvinit ran it from inittab [16:40] where or how you run it, and at which point in the boot, etc. will depend on distro [16:40] and the distro's own needs [16:41] Ok, so when creting init scripts for new things, the recomended way would be to create upstart scripts for them? [16:41] e.g. a distro that hasn't migrated to Upstart fully might consider the /etc/init.d scripts still authorative and run Upstart jobs around/before/after them [16:41] where a distro that's migrated the bulk of its boot to Upstart might consider them an afterthought [16:41] a fully native embedded system might not support them at all [16:41] I'm talking specifically in the context of Ubuntu Karmic [16:41] it depends [16:42] Upstart is still very much in development, so the config file format is expected to change [16:42] so it's ok to ship Upstart jobs, as long as you keep up with Upstart changes [16:42] shipping an Upstart job that refers to "runlevels" is rarely correct of course [16:42] I'm only planning to distribute them internally anyway, so that's not a huge problem. [16:43] in that case upstart scripts give you more power ☺ [16:43] I'm also wondering how far it currently goes with process supervision. Should it be restarting services that get killed for example? [16:44] you can specify whether or not it should do that [16:44] jonwood: it has a basic support for process supervision, and can respawn processes if they die unexpectedly, along with telling it what exit codes and signals are expected [16:45] Where abouts can I find documentation on that? [16:45] in the man pages, of course [16:46] Heh, I guess I asked for that :P [16:46] init(5) mostly [16:48] Thanks :) [17:05] Keybuk: I've thought about making the task stanza an extension of the expect stanza [17:05] Keybuk: "expect exit" [17:06] it doesn't just change that though [17:07] Keybuk: internally its a bit different. Trying to decide whether from a user perspective the metaphor makes sense [17:12] Keybuk: was that a crash? did you catch everything? [17:13] sadmac2: I can't tell whether I caught everything, can I? :p [17:13] 12:06 < Keybuk> it doesn't just change that though [17:13] 12:07 < sadmac2> Keybuk: internally its a bit different. Trying to decide whether from a user perspective the metaphor makes sense [17:13] 12:10 -!- Keybuk [~scott@quest.netsplit.com] has quit [Quit: 夠荒唐] [17:13] wasn't a crash - updated IRC client to restore my notification icon patch [17:13] oic [17:14] I was thinking that task vs. service is fairly well expressed by whether the job uses "while" or "on" [17:14] Keybuk: services with no dependencies would just use on [17:15] no they won't [17:15] Keybuk: it also might make sense for a task to have dependencies [17:16] yes, but they'll just combine while and on ;) [17:16] Keybuk: while postgres every 3 hours exec trivial-database-task [17:16] that'd be a task [17:16] "every" is kinda like "on" [17:16] Keybuk: so you're saying a service will /never/ use on. [17:17] I can't think of one [17:17] while system-running [17:18] Keybuk: you may be right, but it takes a bit of thinking to ferret out. I'm not sure the principle of least surprise would encourage us figuring out task vs service automagically that way. [17:18] don't make the user need to know task/service as a distinction. [17:18] just instruct them to describe how they want the executable to be invoked. [17:19] the primary distinction between a service and a task is how it affects the event it's run by [17:19] blocking it or not? [17:19] blocking it from completing, right [17:19] so a better way to look at it => [17:19] - is the a reason that something run "on " should not ordinarily block it from completing [17:20] - is there a reason that a service run "while" something should block that condition from ever being true [17:20] (reading the latter should reveal it's a logical impossibility :p) [17:21] yes, I prefere while/before to be a first-order implication style relationship [17:21] prefere? In spanish apparently [17:22] right [17:22] Yo preferé que durante/antes son implicaciónes del < uno [17:22] not so bad, and I never took discrete math in spanish, so [17:25] except I mixed tenses. [17:25] what were we talking about? [17:31] task vs. service [17:31] on vs. while [17:35] surprised you answered that seriously... anyway I'm not seeing an approach here that has much real advantage over having a task stanza [17:36] more DWIM [17:37] Keybuk: I'm not sure people necessarily "mean" task when they imply "on". Just because I always use them together doesn't mean they're synonymous [17:37] s/imply/say/ [17:38] so let's think of a few examples [17:38] on service pre-start [17:38] script [17:38] ... [17:38] end script [17:38] would you ever not want that to block? [17:39] Keybuk: true, but there's another question [17:39] Keybuk: would I expect it to block anyway? [17:39] Keybuk: its a strange argument I'm making here. Doing what the user expects is better even if its /not/ what they want. [17:41] Keybuk: look at the example this way: [17:41] on service event [17:41] would I expect that to change the semantics of the job? [17:42] since it always does in Upstart, yes :p [17:43] poor choice of words [17:44] or, another way [17:44] on shutdown [17:44] exec save-my-files [17:44] would you expect it to wait until your files were saved before shutting down? :p [17:45] that's a good point [17:48] Keybuk: where does this leave from ... until ... ? [17:48] dunno yet [17:49] alright I'm sold [17:54] Keybuk: I think we need from...until to turn events we get from outside into upstart states [17:54] Keybuk: netdevice from udev-thingie until other-udev-thingie [17:54] feeling articulate today [17:55] also it would be nice to have a syntax like that somewhere where we could just define a whole bunch of states in a row [17:57] yes, I think we need it [17:57] I'm just not sure whether we consider it like-while or like-on [17:57] hunch says like-while, but would need to think about it [17:58] Keybuk: like on would mean from A until B would block A until B occurred? [17:58] Keybuk: doesn't sound right [18:18] I don't think I'd expect shutdown to complete until the tasks associated with it completed [18:18] after all, if shutdown completes, the system is off. [18:18] heh === rberger_ is now known as rberger === rberger_ is now known as rberger