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