[06:29] <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:30] <johnflux> I maintain the kde 'task manager' thing
[06:30] <johnflux> and interested in having it show the currently running services
[06:31] <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:37] <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:42] <johnflux> a search for "dbus" on the wiki returns zero matches
[15:27] <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:28] <Keybuk> haven't quite decided yet ;)
[15:29] <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:34] <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:35] <mbiebl> to not clutter our maintainer scripts unnecessarily
[15:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <sadmac2> Keybuk: that won't always make sense. Starting metacity without its X dependency doesn't really make sense
[15:45] <Keybuk> sadmac2: that's generally been my thought too
[15:46] <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:47] <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:49] <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:50] <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:51] <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:52] <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:53] <Keybuk> sounds like you need monit or something to test it
[16:18]  * Keybuk wishes bzr had a "bundle working changes" command
[17:52] <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
[18:06] <Keybuk> interestingly, to get the goal, state and process list is three d-bus property requests
[18:07] <Keybuk> which means things can change between them
[19:12] <Keybuk> (implemented GetAll :p)
[19:53] <ion> :-)
[20:18] <wasabi> hi long time no seen
[20:36] <ion> Howdy