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