| === robbiew is now known as robbiew_ | ||
| === oojah_ is now known as oojah | ||
| === robbiew_ is now known as robbiew | ||
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| jonwood | Where abouts can I find documentation on that? | 16:45 |
| Keybuk | in the man pages, of course | 16:45 |
| jonwood | Heh, I guess I asked for that :P | 16:46 |
| JanC | init(5) mostly | 16:46 |
| jonwood | Thanks :) | 16:48 |
| sadmac2 | Keybuk: I've thought about making the task stanza an extension of the expect stanza | 17:05 |
| sadmac2 | Keybuk: "expect exit" | 17:05 |
| Keybuk | it doesn't just change that though | 17:06 |
| sadmac2 | Keybuk: internally its a bit different. Trying to decide whether from a user perspective the metaphor makes sense | 17:07 |
| sadmac2 | Keybuk: was that a crash? did you catch everything? | 17:12 |
| 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:13 |
| 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:14 |
| Keybuk | no they won't | 17:15 |
| sadmac2 | Keybuk: it also might make sense for a task to have dependencies | 17:15 |
| 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:16 |
| Keybuk | I can't think of one | 17:17 |
| wasabi | while system-running | 17:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| sadmac2 | yes, I prefere while/before to be a first-order implication style relationship | 17:21 |
| sadmac2 | prefere? In spanish apparently | 17:21 |
| 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:22 |
| sadmac2 | except I mixed tenses. | 17:25 |
| sadmac2 | what were we talking about? | 17:25 |
| Keybuk | task vs. service | 17:31 |
| Keybuk | on vs. while | 17:31 |
| 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:35 |
| Keybuk | more DWIM | 17:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| Keybuk | since it always does in Upstart, yes :p | 17:42 |
| sadmac2 | poor choice of words | 17:43 |
| 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:44 |
| sadmac2 | that's a good point | 17:45 |
| sadmac2 | Keybuk: where does this leave from ... until ... ? | 17:48 |
| Keybuk | dunno yet | 17:48 |
| sadmac2 | alright I'm sold | 17:49 |
| 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:54 |
| 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:55 |
| 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:57 |
| sadmac2 | Keybuk: like on would mean from A until B would block A until B occurred? | 17:58 |
| sadmac2 | Keybuk: doesn't sound right | 17:58 |
| 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 | 18:18 |
| === rberger_ is now known as rberger | ||
| === rberger_ is now known as rberger | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!