johnfluxHey all06:29
johnfluxI come in here every few months to check on the status of upstart06:29
johnfluxAny news on being able to see what services are running as a normal user?06:29
johnfluxI maintain the kde 'task manager' thing06:30
johnfluxand interested in having it show the currently running services06:30
johnfluxthere were plans for being able to query this information via dbus.  Is this still be considered?06:31
johnfluxCould policykit be used for this instead?06:31
johnfluxThe webpage says:06:37
johnfluxFeatures...# Communication with the init daemon over D-Bus06:37
johnfluxalthough I can't see anything upstart-like with qdbus06:37
johnfluxbut perhaps because ubuntu uses 0.3.906:37
johnfluxa search for "dbus" on the wiki returns zero matches06:42
mbieblKeybuk: reading the backlog: what will be the location for upstart job files for 0.6?15:27
mbiebland will a *.conf suffix be mandatory15:27
Keybukhaven't quite decided yet ;)15:28
Keybuk0.3 uses /etc/event.d/*15:29
Keybuk0.5 uses /etc/init/jobs.d/*15:29
Keybuk0.10 will use /etc/init/*.conf15:29
mbieblif 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 directly15:34
mbieblto not clutter our maintainer scripts unnecessarily15:35
mbieblKeybuk: been watching your presentation for fosdem15:37
Keybukright, it's an interesting decision15:37
Keybukif we go with /etc/event.d - it's a bit more compatible with 0.3 (assuming the jobs work unmodified)15:37
Keybukbut that leaves the people using 0.5 out in the cold15:37
Keybukif 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 compatible15:38
mbiebland 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 automatically15:38
mbieblwhen I run "start foo"15:38
Keybukreally, why not?  if you want foo running, you want it running ;)15:39
sadmac2mbiebl: upstart doesn't have such an idea15:39
sadmac2mbiebl: dbus and hal will start foo. starting foo without dbus and hal just bitches about not having dbus and hal15:40
Keybuksadmac2: not true, in 0.10 starting foo will start dbus and hal15:40
mbieblsadmac2: that's not how I understood the presentation15:40
sadmac2Keybuk: that's not particularly event-driven...15:40
mbieblKeybuk: I'd say, if I run "start foo", upstart should simply ignore the "dependencies"15:41
Keybuksadmac2: nor is having a "start" command in the first place15:41
mbieblor at least provide a switch, which allows that15:42
sadmac2Keybuk: true15:42
Keybuksadmac2: which is all we're talking about here; there's no facility for foo to be automatically started and cause dbus/hal to be started15:42
sadmac2Keybuk: so if I have when file-exists /etc/foo.conf will doing start foo create foo.conf ? :P15:42
Keybuksadmac2: no, that will fail ;)15:42
Keybukmbiebl: you need to know which dbus and hal to be associated with15:43
Keybukmbiebl: since you need to resolve which instance of foo to start15:43
Keybukmbiebl: you can obviously create a new foo instance and start that - without its dependencies15:43
sadmac2Keybuk: that won't always make sense. Starting metacity without its X dependency doesn't really make sense15:44
Keybuksadmac2: that's generally been my thought too15:45
sadmac2Keybuk: 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
Keybuksadmac2: I've always envisioned that you can force creation of an instance without its dependencies15:46
Keybukand that in that situation, it's up to you to provide the necessary environment that would otherwise come from them15:46
Keybukobviously such an instance would never be automatically stopped15:47
mbieblKeybuk: I think we need the ability to start a job while ignoring it's dependencies15:47
sadmac2Keybuk: its an ugly thing to do but it can be possible15:47
Keybukmbiebl: I don't think it should be the default behaviour though15:47
sadmac2Keybuk: 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
mbieblI'll try to put my thoughts, why we need it into an email an send it to the debian initscripts list15:49
Keybukupstart-devel better surely?15:49
sadmac2mbiebl: ^^what he said15:50
Keybuksadmac2: seems reasonable15:50
sadmac2Keybuk: you want a fun challenge, figure out how to manage ypbind :)15:50
Keybuksadmac2: I don't know what that is15:50
mbieblKeybuk: the main reason, why I want this, is to make upstart-job work properly15:50
mbieblwhich will be Debian/Ubuntu specific15:51
sadmac2Keybuk: NIS. Its abysmally built. Figuring out whether its actually running and doing what it should is a quantum uncertainty problem15:51
sadmac2Keybuk: It'll start, say "ok" and then just be sitting there not responding to requests15:51
Keybukpost-start exec sleep 1015:52
sadmac2Keybuk: not for an interval15:52
sadmac2Keybuk: permanently15:52
sadmac2Keybuk: if it doesn't find a server or something it just idles15:52
sadmac2Keybuk: and never recovers15:52
Keybuksounds like you need monit or something to test it15:53
* Keybuk wishes bzr had a "bundle working changes" command16:18
Keybukquest util% ./initctl start --no-wait slow-starter17:52
Keybukslow-starter start/pre-start, process 742517:52
Keybuk--no-wait works again17:52
Keybukinterestingly, to get the goal, state and process list is three d-bus property requests18:06
Keybukwhich means things can change between them18:07
Keybuk(implemented GetAll :p)19:12
wasabihi long time no seen20:18

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!