| 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? | 09:50 |
|---|---|---|
| mgoetze | tstone: in principle those two things will happen in parallel, so perhaps you want "start on stopped dbus" | 11:55 |
| tstone | mgoetze: which is kind of bad if this is a "reboot -f" | 12:19 |
| 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 | 12:24 |
| 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:34 |
| 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:41 |
| ion | tstone: ↑ | 14:42 |
| 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:44 |
| 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:45 |
| tstone | ntr0py: just add a "and started SERVICENAME" to the line beginning with start. | 14:46 |
| 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:47 |
| 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:48 |
| tstone | ntr0py: ahem "cd /etc/init; grep ^start *" | 14:50 |
| ntr0py | thx already did that... | 14:50 |
| tstone | ntr0py: thats the way you can add addtional deps for starting a service | 14:51 |
| ntr0py | tstone: do you know what starts the nvidia proprietary driver? | 14:55 |
| 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:56 |
| ion | I would guess the X.org driver. | 14:57 |
| 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:01 |
| plautrba | tstone: you can still have <fork/> in your dbus-deamon config file | 15:03 |
| 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:05 |
| 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:08 |
| ntr0py | or is it /dev/nvidia0 ?? | 15:09 |
| ion | I’m quite sure the proprietary driver handles all that. | 15:11 |
| ntr0py | ion: yes i want to trigger gdm start on nvidia driver beeing ready... | 15:12 |
| tstone | ntr0py: sorry don't know | 15:17 |
| tstone | is it correct that if devtmpfs is activated udevtrigger.conf is obsolete? | 16:09 |
| 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:15 |
| mbiebl | AxillIum: man 5 init | 16:18 |
| mbiebl | look for env | 16:18 |
| 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:23 |
| mastamind | does upstart really depend on dbus? | 16:44 |
| 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:49 |
| JanC | AxillIum: why wouldn't it get accepted "on the highest level" ? | 16:52 |
| ion | mastamind: The protocol implementation, yes. The daemon, nope. | 16:54 |
| mastamind | ion: does the initctl (or what ever is used to emit events) need dbus to talk to the daemon? | 16:56 |
| 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 | 16:58 |
| tech404 | didn't follow far enough | 17:02 |
| tech404 | nm, sorry I'm just thinking out loud now | 17:02 |
| mastamind | ion: ldd /sbin/init shows that dbus is a required library... :-( | 17:08 |
| ion | What’s the problem? | 17:11 |
| mastamind | upstart depends on dbus. | 17:11 |
| ion | What’s the problem? | 17:13 |
| mastamind | that IS the problem. | 17:13 |
| mastamind | :-) | 17:13 |
| ion | Upstart also depends on libc. That sucks. Let’s implement our own malloc, strndup, open, fork etc! | 17:14 |
| mastamind | ion: do you really think, that impresses me? | 17:15 |
| mastamind | or anyone else here? | 17:15 |
| ion | Nope. | 17:15 |
| mastamind | :-) | 17:15 |
| JanC | "I hate DBUS, so I'm l33t" | 17:32 |
| ion | In Soviet Russia, D-BUS hates you. | 17:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!