If you call openlog() with LOG_KERN as the facility, it treats this as not specifying a facility at all, and defaults to LOG_USER. Thus there is no way to get anything logged in the 'kern' facility. The kernel is no exception, as klogd simply calls openlog() with LOG_KERN like any other userland process. I observed this on FC4 (glibc 2.3.6-3) but verified it looking at the latest syslog.c and sys/syslog.h (1.49 and 1.17) in the CVS web access. LOG_KERN is defined to be 0, but on line 341 of syslog.c, we ignore any facility of 0 passed to openlog(), so the default of LOG_USER, assigned on line 70, is kept. Similarly, on lines 164-165, we see that a facility of 0 is considered "not specified".
I'm guessing now that this was intentional, to make it harder for userland programs to "spoof" messages from the kernel. I see that klogd has its own implementation of this API which seems to be about the same, except with this limitation removed.
...so if this behavior is maintained, perhaps the openlog() man page could mention that LOG_KERN for the facility parameter is actually treated as LOG_USER.
From my reading of POSIX, openlog ("something", LOG_PID|LOG_CONS, 0) is supposed to use current default facility value: http://www.opengroup.org/onlinepubs/009695399/functions/openlog.html "If no facility value is specified, the current default facility value is used." FYI LOG_KERN is not among valid facility arguments in POSIX.
The behavior is correct. Userlevel simply isn't allowed to log with LOG_KERN.
I realize this is a very old bug report but I would like to request another look. The klogd implementation in BusyBox suffers from this problem even today (14 years after this bug was reported). It generates messages using the LOG_KERN facility but they show up in the system log with the LOG_USER facility. ltrace shows: openlog("kernel", 0, 0) syslog(5, "klogd started: %s", "BusyBox v1.33.0 (2021-03-08 20:48:21 MST)") strace shows: sendto(3, "<13>Mar 9 17:58:45 kernel: klogd started: BusyBox v1.33.0 (2021-03-08 20:48:21 MST)", 84, MSG_NOSIGNAL, NULL, 0) /var/log/messages contains: Mar 9 17:58:45 myhost user.notice kernel: klogd started: BusyBox v1.33.0 (2021-03-08 20:48:21 MST) This is incorrect. The socket write generated by syslog(3) should be using <5> which is kernel.notice instead of <13> which is user.notice. In my opinion glibc interpreted the POSIX standard incorrectly. It states the following with regard to openlog(): "The facility argument encodes a default facility to be assigned to all messages that do not have an explicit facility already encoded. The initial default facility is LOG_USER." My reading is that the default facility is LOG_USER until a call to openlog() changes it. In the example above klogd called openlog() with 'facility' set to LOG_KERN. I am not convinced by the argument that user mode is not allowed to use LOG_KERN. Any user mode application can open a socket to '/dev/log' and send a message with priority <0> through <7>. As originally reported: that is exactly what some implementations of klogd (which runs in user mode) do in order to circumvent this problem.
Fixed on 2.34.