| johnflux | Hey all | 06:29 |
|---|---|---|
| johnflux | I come in here every few months to check on the status of upstart | 06:29 |
| johnflux | Any news on being able to see what services are running as a normal user? | 06:29 |
| johnflux | I maintain the kde 'task manager' thing | 06:30 |
| johnflux | and interested in having it show the currently running services | 06:30 |
| johnflux | there were plans for being able to query this information via dbus. Is this still be considered? | 06:31 |
| johnflux | Could policykit be used for this instead? | 06:31 |
| johnflux | The webpage says: | 06:37 |
| johnflux | Features...# Communication with the init daemon over D-Bus | 06:37 |
| johnflux | although I can't see anything upstart-like with qdbus | 06:37 |
| johnflux | but perhaps because ubuntu uses 0.3.9 | 06:37 |
| johnflux | a search for "dbus" on the wiki returns zero matches | 06:42 |
| mbiebl | Keybuk: reading the backlog: what will be the location for upstart job files for 0.6? | 15:27 |
| mbiebl | and will a *.conf suffix be mandatory | 15:27 |
| Keybuk | haven't quite decided yet ;) | 15:28 |
| Keybuk | 0.3 uses /etc/event.d/* | 15:29 |
| Keybuk | 0.5 uses /etc/init/jobs.d/* | 15:29 |
| Keybuk | 0.10 will use /etc/init/*.conf | 15:29 |
| mbiebl | if we want to ship 0.6 in Debian/Ubuntu, I'm wondering if we should keep /etc/event.d for 0.6 or go to /etc/init/*.conf directly | 15:34 |
| mbiebl | to not clutter our maintainer scripts unnecessarily | 15:35 |
| mbiebl | Keybuk: been watching your presentation for fosdem | 15:37 |
| Keybuk | right, it's an interesting decision | 15:37 |
| Keybuk | if we go with /etc/event.d - it's a bit more compatible with 0.3 (assuming the jobs work unmodified) | 15:37 |
| Keybuk | but that leaves the people using 0.5 out in the cold | 15:37 |
| Keybuk | if we're not quite compatible with either, we may as well just go straight to /etc/init/*.conf and make sure 0.10 is backwards compatible | 15:38 |
| mbiebl | and I'm not sure if I like the idea of having "while dbus and hal" in a job called foo, make those service be started automatically | 15:38 |
| mbiebl | when I run "start foo" | 15:38 |
| Keybuk | really, why not? if you want foo running, you want it running ;) | 15:39 |
| sadmac2 | mbiebl: upstart doesn't have such an idea | 15:39 |
| sadmac2 | mbiebl: dbus and hal will start foo. starting foo without dbus and hal just bitches about not having dbus and hal | 15:40 |
| Keybuk | sadmac2: not true, in 0.10 starting foo will start dbus and hal | 15:40 |
| mbiebl | sadmac2: that's not how I understood the presentation | 15:40 |
| sadmac2 | Keybuk: that's not particularly event-driven... | 15:40 |
| mbiebl | Keybuk: I'd say, if I run "start foo", upstart should simply ignore the "dependencies" | 15:41 |
| Keybuk | sadmac2: nor is having a "start" command in the first place | 15:41 |
| mbiebl | or at least provide a switch, which allows that | 15:42 |
| sadmac2 | Keybuk: true | 15:42 |
| Keybuk | sadmac2: which is all we're talking about here; there's no facility for foo to be automatically started and cause dbus/hal to be started | 15:42 |
| sadmac2 | Keybuk: so if I have when file-exists /etc/foo.conf will doing start foo create foo.conf ? :P | 15:42 |
| Keybuk | sadmac2: no, that will fail ;) | 15:42 |
| Keybuk | mbiebl: you need to know which dbus and hal to be associated with | 15:43 |
| Keybuk | mbiebl: since you need to resolve which instance of foo to start | 15:43 |
| Keybuk | mbiebl: you can obviously create a new foo instance and start that - without its dependencies | 15:43 |
| sadmac2 | Keybuk: that won't always make sense. Starting metacity without its X dependency doesn't really make sense | 15:44 |
| Keybuk | sadmac2: that's generally been my thought too | 15:45 |
| sadmac2 | Keybuk: we need to adjust that semantics draft I wrote to reflect that. Right now it doesn't allow an instance to exist without its dependencies. | 15:46 |
| Keybuk | sadmac2: I've always envisioned that you can force creation of an instance without its dependencies | 15:46 |
| Keybuk | and that in that situation, it's up to you to provide the necessary environment that would otherwise come from them | 15:46 |
| Keybuk | obviously such an instance would never be automatically stopped | 15:47 |
| mbiebl | Keybuk: I think we need the ability to start a job while ignoring it's dependencies | 15:47 |
| sadmac2 | Keybuk: its an ugly thing to do but it can be possible | 15:47 |
| Keybuk | mbiebl: I don't think it should be the default behaviour though | 15:47 |
| sadmac2 | Keybuk: I've also wondered about having a softer mode of dependencies (not all services have to be restarted if they lose a dependency, so long as the dependency comes back in a reasonable time frame) | 15:47 |
| mbiebl | I'll try to put my thoughts, why we need it into an email an send it to the debian initscripts list | 15:49 |
| Keybuk | upstart-devel better surely? | 15:49 |
| sadmac2 | mbiebl: ^^what he said | 15:50 |
| Keybuk | sadmac2: seems reasonable | 15:50 |
| sadmac2 | Keybuk: you want a fun challenge, figure out how to manage ypbind :) | 15:50 |
| Keybuk | sadmac2: I don't know what that is | 15:50 |
| mbiebl | Keybuk: the main reason, why I want this, is to make upstart-job work properly | 15:50 |
| mbiebl | which will be Debian/Ubuntu specific | 15:51 |
| sadmac2 | Keybuk: NIS. Its abysmally built. Figuring out whether its actually running and doing what it should is a quantum uncertainty problem | 15:51 |
| sadmac2 | Keybuk: It'll start, say "ok" and then just be sitting there not responding to requests | 15:51 |
| Keybuk | post-start exec sleep 10 | 15:52 |
| sadmac2 | Keybuk: not for an interval | 15:52 |
| sadmac2 | Keybuk: permanently | 15:52 |
| sadmac2 | Keybuk: if it doesn't find a server or something it just idles | 15:52 |
| sadmac2 | Keybuk: and never recovers | 15:52 |
| Keybuk | sounds like you need monit or something to test it | 15:53 |
| * Keybuk wishes bzr had a "bundle working changes" command | 16:18 | |
| Keybuk | quest util% ./initctl start --no-wait slow-starter | 17:52 |
| Keybuk | slow-starter start/pre-start, process 7425 | 17:52 |
| Keybuk | yay | 17:52 |
| Keybuk | --no-wait works again | 17:52 |
| Keybuk | interestingly, to get the goal, state and process list is three d-bus property requests | 18:06 |
| Keybuk | which means things can change between them | 18:07 |
| Keybuk | (implemented GetAll :p) | 19:12 |
| ion | :-) | 19:53 |
| wasabi | hi long time no seen | 20:18 |
| ion | Howdy | 20:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!