[09:50] <tstone> 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] <mgoetze> tstone: in principle those two things will happen in parallel, so perhaps you want "start on stopped dbus"
[12:19] <tstone> mgoetze: which is kind of bad if this is a "reboot -f"
[12:24] <tstone> it would be nice to have an event if all managed jobs are stopped
[12:24] <tstone> without having to name all these jobs
[14:34] <tstone> 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] <ntr0py> 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] <ion> With the “system” job, there would be no shutdown job: the system job would handle shutdown/reboot in post-stop.
[14:41] <ion> If you know and control exactly how the job’s main process behaves wrt. forking, it’s okay.
[14:41] <ntr0py> ??
[14:42] <ion> tstone: ↑
[14:44] <tstone> 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] <ion> It indicates the service is ready. In which scenario does it get the state wrong?
[14:45] <ntr0py> does someone know where the start for gdm is defined in ubuntu lucid?
[14:46] <tstone> ntr0py: just add a "and started SERVICENAME" to the line beginning with start.
[14:47] <tstone> ion: i *think* (unfortunatly unverified) that it happens if dbus-daemon doesn't start when the pid file is left over.
[14:47] <ion> Upstart doesn’t care about pid files.
[14:47] <tstone> ion: yes, but dbus-daemon unfortunatly does :-/
[14:48] <ntr0py> tstone: im not exaclty getting it... what do you mean ?
[14:48] <tstone> ntr0py: just do a "cd /etc/init; grep ^start" and try to understand
[14:50] <tstone> ntr0py: ahem "cd /etc/init; grep ^start *"
[14:50] <ntr0py> thx already did that...
[14:51] <tstone> ntr0py: thats the way you can add addtional deps for starting a service
[14:55] <ntr0py> tstone: do you know what starts the nvidia proprietary driver?
[14:56] <tstone> ntr0py: sorry don't know but you can enable debugging by adding --debug to the cmdline.
[14:56] <tstone> i would gues module-init-tools
[14:57] <ion> I would guess the X.org driver.
[15:01] <tstone> 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] <plautrba> tstone: you can still have <fork/> in your dbus-deamon config file
[15:05] <tstone> 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] <ntr0py> 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] <ntr0py> or is it /dev/nvidia0 ??
[15:11] <ion> I’m quite sure the proprietary driver handles all that.
[15:12] <ntr0py> ion: yes i want to trigger gdm start on nvidia driver beeing ready...
[15:17] <tstone> ntr0py: sorry don't know
[16:09] <tstone> is it correct that if devtmpfs is activated udevtrigger.conf is obsolete?
[16:15] <AxillIum> 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] <mbiebl> AxillIum: man 5 init
[16:18] <mbiebl> look for env
[16:23] <AxillIum> 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] <mastamind> does upstart really depend on dbus?
[16:49] <tech404> 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] <JanC> AxillIum: why wouldn't it get accepted "on the highest level" ?
[16:54] <ion> mastamind: The protocol implementation, yes. The daemon, nope.
[16:56] <mastamind> ion: does the initctl (or what ever is used to emit events) need dbus to talk to the daemon?
[16:58] <tech404> 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] <tech404> didn't follow far enough
[17:02] <tech404> nm, sorry I'm just thinking out loud now
[17:08] <mastamind> ion: ldd /sbin/init shows that dbus is a required library... :-(
[17:11] <ion> What’s the problem?
[17:11] <mastamind> upstart depends on dbus.
[17:13] <ion> What’s the problem?
[17:13] <mastamind> that IS the problem.
[17:13] <mastamind> :-)
[17:14] <ion> Upstart also depends on libc. That sucks. Let’s implement our own malloc, strndup, open, fork etc!
[17:15] <mastamind> ion: do you really think, that impresses me?
[17:15] <mastamind> or anyone else here?
[17:15] <ion> Nope.
[17:15] <mastamind> :-)
[17:32] <JanC> "I hate DBUS, so I'm l33t"
[17:37] <ion> In Soviet Russia, D-BUS hates you.