[00:02] Keybuk: btw, I am not sure I understand your implementation [00:03] I mean the bootlogd of the sysvinit is much longer. [00:03] I understand you just open the /dev/kmsg up for writing, but... ;) [00:04] http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/bootlogd.c?root=sysvinit&view=markup [00:08] right [00:08] bootlogd is a really complicated thing that never works [00:08] it *tries* to work by redirecting console output into itself with an ioctl [00:08] (assumedly into a tty) [00:08] and then buffering that output internally until a filesystem is available (by constantly trying to write) [00:08] and then finally once a filesystem is available, flushing out, and then carrying on writing [00:08] the thing is [00:09] bootlogd rarely works [00:09] because it relies on a whole massive stack of things that generally you don't have in the earliest phases of boot [00:09] so I cheated :p [00:09] my patch makes init stuff its output into the kernel's own log system [00:09] rotfl ;) [00:09] (the same one that printk() uses in the kernel) [00:09] that's already buffered by the kernel [00:09] and you can change the size of that buffer on the command-line if it overflows [00:10] and there are well understood mechanisms for getting the data out (dmesg) [00:10] or for flushing and writing to files after (klogd) [00:10] etc. [00:10] the only thing it needs is /dev/kmsg, which tends to exist fairly early [00:10] thanks to devtmpfs :) [00:10] (where fairly early is before userspace) [00:10] you might want to mention these information on the mailing list before others start asking or to just englighten others about the differences. [00:11] if people ask, I shall answer [00:11] let me ask it there :P [00:12] so it needs devtmpfs...mg. [00:12] * I mean mmh [00:12] so what happens before mounting that ? [00:13] 'it *tries* to work by redirecting console output into itself with an ioctl' and 'bootlogd rarely works' -> sounds hilarious in a way ;) [00:14] I mean it is so old stuff, I would expect it is quite stable. [00:41] Keybuk: could this same trick be used for bug #328881 ? or.. did I miss where you said thats the whole point? [00:43] Keybuk: I know the plan for that bug (logging job output) is to use a ring buffer inside upstart.. which I think would be preferrable.. [00:43] djszapi: before that, it'll probably just fail to log [00:43] but since /dev will be one of the very first things you create ... [00:44] SpamapS: right, it's quite different [00:44] Keybuk: sounds about bad :) [00:44] I don't think we want to dump job output into dmesg ;) [00:45] but the bootlogd implementation depends on the /dev too as long as it tries to write it, thus...can be tolerated :P [00:45] yeah [00:46] bootlogd actually usually depends on /dev *and* /dev/pts [00:46] and in many situations, /dev/pts might be one of the very last things you setup (since nominally, you don't need it until you come to fiddling with xterms) [00:47] (you could always mknod /dev/kmsg in your initramfs, if you have one :p) [00:48] yeah, I see. [00:48] *giggles* [00:48] fine with me then, I do not just understand why that hackery exists at all :P [00:48] because this is not a solved problem [00:49] huh ? [00:49] doing anything (such as logging) during boot [00:49] it's not a solved problem [00:49] so hackery is required [00:49] well..... [00:50] did you see the mail in 2002 about it on the kernel mailing list ? :) [00:52] "it" [00:52] and my god, you expect me to remember an LKML mail from 9 years ago?! [00:52] have you SEEN the traffic on that list?! :p [00:52] well you should ;) [00:52] hehe :P [00:52] no, I really shouldn't [00:52] :p [00:52] muhah [00:53] well it was interesting thread in fact. [00:53] targetting the issue we are talking about :) [00:53] but anyway...3 am, ty again ninis :) [04:54] is su the only way to run jobs as unprivileged users right now? [05:20] How do i figure out which rule caused this message? [05:20] start: Rejected send message, 1 matched rules; type="method_call"