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