[00:02] <djszapi> Keybuk: btw, I am not sure I understand your implementation
[00:03] <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:04] <djszapi> http://svn.savannah.nongnu.org/viewvc/sysvinit/trunk/src/bootlogd.c?root=sysvinit&view=markup
[00:08] <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:09] <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:10] <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:11] <Keybuk> if people ask, I shall answer
[00:11] <djszapi> let me ask it there :P
[00:12] <djszapi> so it needs devtmpfs...mg.
[00:12] <djszapi> * I mean mmh
[00:12] <djszapi> so what happens before mounting that ?
[00:13] <djszapi> 'it *tries* to work by redirecting console output into itself with an ioctl' and 'bootlogd rarely works' -> sounds hilarious in a way ;)
[00:14] <djszapi> I mean it is so old stuff, I would expect it is quite stable.
[00:41] <SpamapS> Keybuk: could this same trick be used for bug #328881 ? or.. did I miss where you said thats the whole point?
[00:43] <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:44] <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:45] <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:46] <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:47] <Keybuk> (you could always mknod /dev/kmsg in your initramfs, if you have one :p)
[00:48] <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:49] <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:50] <djszapi> did you see the mail in 2002 about it on the kernel mailing list ? :)
[00:52] <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:53] <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 :)
[04:54] <seventoes> is su the only way to run jobs as unprivileged users right now?
[05:20] <seventoes> How do i figure out which rule caused this message?
[05:20] <seventoes> start: Rejected send message, 1 matched rules; type="method_call"