| soren | damjan: Funny you should ask... | 00:09 |
|---|---|---|
| soren | damjan: https://bugs.launchpad.net/bugs/372864 | 00:10 |
| damjan | funny as in, you are laughing all the way to the bank? :) | 00:10 |
| damjan | thanks | 00:11 |
| soren | Sure :) | 00:11 |
| damjan | I don't think this is available in 0.6.3 .. (does launchpad corellate bug reports with commits??) | 00:13 |
| ion | Karmic has 0.6.3, so what Scott said in the last message would work with it. | 00:15 |
| ion | The tty-device-added event must come from upstart-udev-bridge. | 00:16 |
| ion | Indeed, strings =upstart-udev-bridge: | 00:16 |
| ion | %s-device-added | 00:16 |
| ion | KERNEL=%s | 00:16 |
| Keybuk | it does | 00:18 |
| damjan | is upstart-udev-bridge going to be included in future upstart versions? | 00:38 |
| ion | Future Upstart versions won’t need it, as they’ll have the functionality built-in. | 00:39 |
| damjan | ion: how do you know this stuff? (it's a bit hard to come by upstart info) | 00:40 |
| ion | damjan: The upstart-udev-bridge man page says sos. | 00:41 |
| ion | so | 00:41 |
| damjan | ahh :) | 00:41 |
| Keybuk | damjan: you can just ask for upstart info ;) | 00:41 |
| damjan | Keybuk: the problem is when you don't know what to ask ... Upstart is still new (and changing) and has possibilities that weren't available before | 00:42 |
| Keybuk | that's certainly true | 00:43 |
| damjan | I'm experimenting with Upstart on ArchLinux .. so far I have it working | 00:44 |
| * Esmil too ;) | 00:44 | |
| ion | http://xkcd.com/645/ :-D | 02:33 |
| testi_ | In 9.04 Upstart does not emit an event when a network device goes up, or a default route is added. How can I execute a script as soon as network is available (without busy waiting!) | 07:42 |
| testi_ | Ubuntu 9.04 | 07:42 |
| Md | testi_: use udev | 07:52 |
| testi_ | okay | 07:53 |
| testi_ | Hmm but there is an example event network-up (that is not emitted in Ubuntu). Use udev because upstart is incomplete? Or use udev to tellupstart that a ertain device has now an ip-adress? | 08:17 |
| === mbiebl_ is now known as mbiebl | ||
| spaetz | Hi | 13:21 |
| spaetz | Is it intended that a "restart dbus" kills my X server and restarts it? | 13:22 |
| Keybuk | yes | 13:22 |
| spaetz | without notifying or asking me? | 13:22 |
| Keybuk | you told it to, why would it ask you? | 13:22 |
| spaetz | because update-manager upgraded dbus which killed the X session which ran the update | 13:23 |
| spaetz | and therefore my upgrade was left in a state of limbo with a non-functioning network-manager | 13:23 |
| Keybuk | update-manager does not run "restart dbus" | 13:23 |
| Keybuk | if you had a bug like that, you should contact your distribution | 13:23 |
| * spaetz shrugs. All I did was running update-manager and it suddently restarted X | 13:23 | |
| spaetz | I understand that living on the beta-edge will expose me to stuff like that | 13:24 |
| spaetz | but it's quite annoying. Also I used to /etc/init.d/dbus restart just fine without having X killed | 13:24 |
| spaetz | so if you are not aware of the dependency tree, a lot of bad stuff can happen | 13:24 |
| spaetz | who knows what else X depends on... | 13:25 |
| Keybuk | I don't see that it's a bug | 13:25 |
| Keybuk | if you're restarting services without understanding what depends on them, you deserve everything you get ;-) | 13:25 |
| spaetz | it might not be a bug, strictly speaking. But I am very much afraid of restarting *any* service now when in a X session. | 13:26 |
| spaetz | So, is there an easy way to find out the dependency tree? | 13:26 |
| spaetz | If there is none, then I'd consider that missing crucial functionality :) | 13:26 |
| Keybuk | no, because upstart doesn't work by dependencies | 13:26 |
| spaetz | so, how do I find out what else would kill my X? | 13:27 |
| Keybuk | read the /etc/init/gdm.conf fiole | 13:27 |
| spaetz | e.g. restart hal? dbus? cups? How can I find out? | 13:27 |
| spaetz | will do, and thanks for your patience | 13:28 |
| Keybuk | and then you'll discover that Upstart had no part in your X server restarting | 13:28 |
| Keybuk | and, in fact, your X server crashed *all by itself* | 13:28 |
| spaetz | Keybuk: no crash. Windows suddently started closing one after the other | 13:28 |
| Keybuk | it's crashing, just awkwardly ;) | 13:28 |
| spaetz | hehe, ok. I'll read the gdm.com stuff and check it out | 13:29 |
| spaetz | fortunately, i didn't have important stuff open | 13:29 |
| spaetz | the critical line seems to be: start on (filesystem and started hal) | 13:30 |
| spaetz | so when hal stops, gdm would stop | 13:30 |
| spaetz | and I assume hal depends on dbus | 13:31 |
| spaetz | ahh, and on udev. So no more udev restarts with running X either. | 13:31 |
| Keybuk | no | 13:31 |
| Keybuk | incorrect | 13:31 |
| Keybuk | that means that when hal is started, gdm is started | 13:31 |
| Keybuk | the "stop on" line is all about stopping, and that doesn't mention hal | 13:32 |
| spaetz | so when hal stops, gdm wouldn't stop? ok | 13:32 |
| spaetz | so then "restart dbus" making X restart must be a crash | 13:32 |
| spaetz | I recommend to write a blog post about that :) | 13:32 |
| Keybuk | when hal stops, X crashes | 13:33 |
| Keybuk | that's quite different | 13:33 |
| Keybuk | blog away ;) | 13:33 |
| spaetz | may, I quote bits of our conversation to make things clear? | 13:34 |
| spaetz | -> "may I..." | 13:34 |
| Keybuk | sure | 13:35 |
| Keybuk | though my conversation isn't exactly reveraling | 13:36 |
| spaetz | hehe, was interesting enough to me, thanks for the time to explain stuff | 13:36 |
| spaetz | next 24 days must be quite busy :) | 13:37 |
| spaetz | bye | 13:38 |
| mgoetze | Keybuk: about #433270 - where do those tty-device-added events come from? upstart itself? or do i need an appropriate udev configuration to emit them? | 13:39 |
| Keybuk | upstart-udev-bridge | 13:45 |
| mgoetze | that seems to exist in ubuntu, but i don't use ubuntu... | 13:47 |
| spaetz | I'll probably cut out some parts of the conversation later. But here is a draft quoting us (it's more than bits for now :-) ): http://sspaeth.de/archives/1191-Upstart-killed-the-Video-star.html | 13:48 |
| Keybuk | spaetz: the title is rather misleading | 13:54 |
| Keybuk | since we already established that it's X that dies on its own | 13:55 |
| Keybuk | sorry, but your blog post has no use | 13:55 |
| Keybuk | you're not documenting anything, just bitching | 13:56 |
| Keybuk | so I recall my permission to use anything I've said there | 13:56 |
| * spaetz shrugs. Your call. Will remove the quoting. | 13:58 | |
| spaetz | we, did start the conversation that way though: 14:22 < spaetz> Is it intended that a "restart dbus" kills my X server and restarts it? | 13:58 |
| spaetz | 14:22 < Keybuk> yes | 13:58 |
| damjan | spaetz: yep, that dependecy on the system dbus in the X server is a new "feature" | 14:12 |
| damjan | ... and it sucks | 14:12 |
| damjan | btw, when I was asking (don't remmember what channel) the response was "dbus shouldn't be restarted" | 14:13 |
| spaetz | damjan: agreed | 14:13 |
| damjan | .. ever | 14:13 |
| spaetz | haha. Code just shouldn't crash, mem leaks not happen, and Microsoft play nice :-) | 14:13 |
| spaetz | everything should stand a reload of some other service without crashing on me | 14:14 |
| mgoetze | spaetz: go ahead and write an operating system in erlang then. we're all looking forward to the result, i can tell you | 14:15 |
| damjan | well, at least Dbus could be written in erlang :) | 14:17 |
| damjan | incerdible, there isn't even a bug report on bugs.freedesktop.org | 14:17 |
| * spaetz doesn't see what erland has to do with the fact that Xorg seems to have made a design decision that is just plain silly | 14:18 | |
| spaetz | s/erland/erlang/ | 14:18 |
| damjan | spaetz: an erlang dbus service could "restart" itself without bringing down the connections | 14:19 |
| damjan | but yeah, the Xorg server just uses the standard lib that doesn't handle disconnections from the bus AFAIK | 14:19 |
| spaetz | I see | 14:21 |
| damjan | but this bug report claims it's a problem in gnome-session http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527860 | 14:23 |
| * spaetz just found the same bug report :). THere is also one for Gentoo and Arch. | 14:24 | |
| damjan | spaetz: do you use Gnome? | 14:24 |
| damjan | ah.. so it was a problem in Awesome too | 14:26 |
| damjan | I should test this again | 14:26 |
| spaetz | Gnome yes. | 14:26 |
| damjan | ok, so in latest Xorg-server and awesome I don't have the problem .. so X is ok :) | 14:28 |
| damjan | xorg-server 1.6.3.901 here | 14:29 |
| === robbiew-afk is now known as robbiew | ||
| === robbiew is now known as robbiew-afk | ||
| === Md_ is now known as Md | ||
| === soren_ is now known as soren | ||
| === robbiew-afk is now known as robbiew | ||
| ion | keybuk: I could rebase the fsck-locking branch against the ubuntu-core-dev branch. Or are you already doing that? | 16:49 |
| ion | keybuk: Rebased and verified to work. | 17:45 |
| ion | keybuk: “Flush standard output and error before spawning processes to make capturing logs easier (otherwise we end up repeating things still in the buffer).” Ah, so that’s what it was. I guessed the behavior must be related to something getting duplicated with the forks that shouldn’t, but i never got around to investigating it. | 18:41 |
| === robbiew is now known as robbiew-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!