[09:50] ion: thanks for elaborating, i'm still a little confused about timing. So i have dbus with "stop on runlevel [06]" and a shutdown.conf with "start on runlevel [06]". Will shutdown be run after dbus has stopped? [11:55] tstone: in principle those two things will happen in parallel, so perhaps you want "start on stopped dbus" [12:19] mgoetze: which is kind of bad if this is a "reboot -f" [12:24] it would be nice to have an event if all managed jobs are stopped [12:24] without having to name all these jobs [14:34] is there a reason that under ubuntu 10.4 dbus is configured to --fork. I thought that it would be better to start the services without forking? [14:41] I have an issue with upstart in Ubuntu 10.04 starting gdm too early (resulting in low graphics mode error). How can i tell upstart to wait with gdm's start until nvidia/dkms is ready? [14:41] With the “system” job, there would be no shutdown job: the system job would handle shutdown/reboot in post-stop. [14:41] If you know and control exactly how the job’s main process behaves wrt. forking, it’s okay. [14:41] ?? [14:42] tstone: ↑ [14:44] ion: ok, but why fork, i mean dbus-daemon can also be started without forking. And i've got the impression that upstart sometimes gets the state of dbus wrong whith this "forking" behaviour. [14:45] It indicates the service is ready. In which scenario does it get the state wrong? [14:45] does someone know where the start for gdm is defined in ubuntu lucid? [14:46] ntr0py: just add a "and started SERVICENAME" to the line beginning with start. [14:47] ion: i *think* (unfortunatly unverified) that it happens if dbus-daemon doesn't start when the pid file is left over. [14:47] Upstart doesn’t care about pid files. [14:47] ion: yes, but dbus-daemon unfortunatly does :-/ [14:48] tstone: im not exaclty getting it... what do you mean ? [14:48] ntr0py: just do a "cd /etc/init; grep ^start" and try to understand [14:50] ntr0py: ahem "cd /etc/init; grep ^start *" [14:50] thx already did that... [14:51] ntr0py: thats the way you can add addtional deps for starting a service [14:55] tstone: do you know what starts the nvidia proprietary driver? [14:56] ntr0py: sorry don't know but you can enable debugging by adding --debug to the cmdline. [14:56] i would gues module-init-tools [14:57] I would guess the X.org driver. [15:01] strange if i remove the --fork and the expect fork from dbus.conf dbus-deamon gets started but is listed as not running by initctrl? [15:03] tstone: you can still have in your dbus-deamon config file [15:05] plautrba: yes, but i was curious why thats in there. Probably it has s.t. to do with the dbus interface of upstart... [15:08] tstone: i absolutely have no experience with upstart but i would GUESS it should be sth like "graphics-device-added /dev/nvidiactl PRIMARY_DEVICE_FOR_DISPLAY=1" ? Pls correct me if im wrong... [15:09] or is it /dev/nvidia0 ?? [15:11] I’m quite sure the proprietary driver handles all that. [15:12] ion: yes i want to trigger gdm start on nvidia driver beeing ready... [15:17] ntr0py: sorry don't know [16:09] is it correct that if devtmpfs is activated udevtrigger.conf is obsolete? [16:15] I hope it's not too much of a n00b question, but I do not seem to find it in the documentation: how do I set a variable in a /etc/init/foo.conf script so I can use it in both pre-start script and the script part for starting the actual job? [16:18] AxillIum: man 5 init [16:18] look for env [16:23] I have found the section, but unfortunately, it does not specify where to put the line. On the highest level it will not get accepted. In the pre-start script it will not keep the value after the pre-start script. [16:44] does upstart really depend on dbus? [16:49] I'd like to start a bittorrent daemon as a user on startup with upstart. I've done some reading on this but I'm not sure about how to approach it. I know there isn't official support now and I'm guessing 'exec su me -c "exec deluged"' is the right way to go as start-stop-daemon would have to much overlap. I'm not sure what other options I should use though. I would think that if I was starting as root I would use 'expect fork' an [16:52] AxillIum: why wouldn't it get accepted "on the highest level" ? [16:54] mastamind: The protocol implementation, yes. The daemon, nope. [16:56] ion: does the initctl (or what ever is used to emit events) need dbus to talk to the daemon? [16:58] nm i guess I would expect fork.. As no one know I'll try without respawn for now to make sure I don't get some crazyness [17:02] didn't follow far enough [17:02] nm, sorry I'm just thinking out loud now [17:08] ion: ldd /sbin/init shows that dbus is a required library... :-( [17:11] What’s the problem? [17:11] upstart depends on dbus. [17:13] What’s the problem? [17:13] that IS the problem. [17:13] :-) [17:14] Upstart also depends on libc. That sucks. Let’s implement our own malloc, strndup, open, fork etc! [17:15] ion: do you really think, that impresses me? [17:15] or anyone else here? [17:15] Nope. [17:15] :-) [17:32] "I hate DBUS, so I'm l33t" [17:37] In Soviet Russia, D-BUS hates you.