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