system-log: Handle raw kernel messages. #67

Yelninei · 2025-10-14T18:50:41+02:00

Yelninei commented

2025-10-14 18:50:41 +02:00

modules/shepherd/service/system-log.scm (%default-kernel-priority): New
variable.
(parse-system-log-message): Add kernel? keyword.
(read-system-log-message): Add kernel-keyword and propagate it.
(run-system-log): Add kernel-port keyword.

This seems to work for the guix hurd (ontop of the wip pr to fix select/poll for streamio)

2025-10-14 16:45:54 localhost vmunix: GNU Mach 1.8
2025-10-14 16:45:54 localhost vmunix: ELF section header table at c00103d0
2025-10-14 16:45:54 localhost vmunix: biosmem: physical memory map:
2025-10-14 16:45:54 localhost vmunix: biosmem: 000000000000000000:00000000000009f000, available

I am using %default-kernel-priority as critical to match inetutils syslogd but the more important thing is setting facility to kernel to let system-log-message->string know that this is a kernel message.

Currently the call to parse-system-log-message in log-bytes is always assumed to be not from the kernel port.
otherwise we would need to propagate this there as well.

It should also work when #:kernel-port is #f because then we would compare a port to #f

* modules/shepherd/service/system-log.scm (%default-kernel-priority): New variable. (parse-system-log-message): Add kernel? keyword. (read-system-log-message): Add kernel-keyword and propagate it. (run-system-log): Add kernel-port keyword. Fixes shepherd/shepherd#46 This seems to work for the guix hurd (ontop of the wip pr to fix select/poll for streamio) ``` 2025-10-14 16:45:54 localhost vmunix: GNU Mach 1.8 2025-10-14 16:45:54 localhost vmunix: ELF section header table at c00103d0 2025-10-14 16:45:54 localhost vmunix: biosmem: physical memory map: 2025-10-14 16:45:54 localhost vmunix: biosmem: 000000000000000000:00000000000009f000, available ``` I am using `%default-kernel-priority` as `critical` to match inetutils syslogd but the more important thing is setting facility to kernel to let `system-log-message->string` know that this is a kernel message. Currently the call to `parse-system-log-message` in `log-bytes` is always assumed to be not from the kernel port. otherwise we would need to propagate this there as well. It should also work when `#:kernel-port` is `#f` because then we would compare a port to `#f`

Yelninei changed title from ~~system-log: Handle raw kernel messages.~~ to WIP: system-log: Handle raw kernel messages.

2025-10-14 18:59:53 +02:00

Yelninei commented

2025-10-15 15:03:36 +02:00

Also one thing that this currently does not do is some validation on the facility:

When printing not a message from the klog inetutils syslog validates that the priority is in the correct range, the facility is not bigger than 24/ the max and prevents the non klog inputs from logging kernel messages by changing it to user.

This would also be doable now because we now know if we decode a kernel message and when not.

Similiarly the #:kernel? parameter only affects the fallback facility and not the facility from a non kernel message in the kernel log.
In the rsyslog documentation i found a note that on some bsds this indeed can happen (https://www.rsyslog.com/doc/configuration/modules/imklog.html)

Also one thing that this currently does not do is some validation on the facility: When printing not a message from the klog inetutils syslog validates that the priority is in the correct range, the facility is not bigger than 24/ the max and prevents the non klog inputs from logging kernel messages by changing it to user. This would also be doable now because we now know if we decode a kernel message and when not. Similiarly the `#:kernel?` parameter only affects the fallback facility and not the facility from a non kernel message in the kernel log. In the rsyslog documentation i found a note that on some bsds this indeed can happen (https://www.rsyslog.com/doc/configuration/modules/imklog.html)

civodul requested changes

2025-10-15 18:27:44 +02:00

civodul left a comment

Overall LGTM.

This one warrants a NEWS entry too.

Thanks!

Overall LGTM. This one warrants a `NEWS` entry too. Thanks!

modules/shepherd/service/system-log.scm

					
				@ -134,3 +134,3 @@

				(define %default-facility (system-log-facility user))

				(define* (parse-system-log-message line #:optional sender)

				(define %default-kernel-priority (system-log-priority critical))

Given that /dev/klog (Hurd) shows primarily debugging info, I would rather make it notice or info. WDYT?

Given that `/dev/klog` (Hurd) shows primarily debugging info, I would rather make it `notice` or `info`. WDYT?

I agree.

I chose critical because it is syslogds default for unknown kenrel messages DEFSPRI (LOG_KERN|LOG_CRIT).

To confirm I also captured the kernel log from syslogd in its debug mode

(logmsg): kern.crit (2), flags 7, from localhost, msg vmunix: GNU Mach 1.8
Logging to FILE /dev/tty12
Logging to FILE /var/log/messages

I tried to look around what other syslogds do in that case but have not found aynthing else yet

I agree. I chose critical because it is syslogds default for unknown kenrel messages `DEFSPRI (LOG_KERN|LOG_CRIT)`. To confirm I also captured the kernel log from syslogd in its debug mode ``` (logmsg): kern.crit (2), flags 7, from localhost, msg vmunix: GNU Mach 1.8 Logging to FILE /dev/tty12 Logging to FILE /var/log/messages ``` I tried to look around what other syslogds do in that case but have not found aynthing else yet

if I unterstand the code correctly syslog-ng and rsyslog both use LOG_NOTICE as default which would give some symmetry with the non kernel case

Yelninei marked this conversation as resolved

modules/shepherd/service/system-log.scm

					
				@ -145,3 +138,3 @@

				       (system-log-message facility+priority

				                           (match:suffix m) sender)))))

				                           (match:substring m 3) sender)))))

Please extend the docstring like:

If @var{line} lacks syslog metadata and @var{kernel?} is true, set the facility of the return value to @code{kernel}.

Please extend the docstring like: ``` If @var{line} lacks syslog metadata and @var{kernel?} is true, set the facility of the return value to @code{kernel}. ```

Yelninei marked this conversation as resolved

modules/shepherd/service/system-log.scm

					
				@ -253,1 +215,3 @@

				          (loop ports))))

				         ((? eof-object?) #t)

				         (line (put-message dispatcher (parse-system-log-message line))))

				       (loop))

Please extend the docstring to say that kernel-port is used solely to determine whether one of the elements of ports corresponds to the kernel log.

Please extend the docstring to say that `kernel-port` is used solely to determine whether one of the elements of `ports` corresponds to the kernel log.

Yelninei marked this conversation as resolved

Yelninei force-pushed yelninei/syslog-raw-kernel from c70c280a10 to 163352e57d

2025-10-16 20:00:06 +02:00

Compare

Yelninei commented

2025-10-16 20:02:46 +02:00

@civodul

Should the socket case i.e. log-bytes also propagate kernel? to parse-system-log-message or can I assume that the kernel log port is not a socket

@civodul Should the socket case i.e. `log-bytes` also propagate `kernel?` to `parse-system-log-message` or can I assume that the kernel log port is not a socket

civodul commented

2025-10-19 16:08:09 +02:00

@Yelninei Let’s assume the kernel log is not a socket. This assumption holds on both Linux and the Hurd, and most likely on other free Unix-style systems.

Yelninei force-pushed yelninei/syslog-raw-kernel from 163352e57d to b4e4facb15

2025-10-19 17:37:54 +02:00

Compare

Yelninei commented

2025-10-19 17:39:27 +02:00

Added a news entry (and also corrected the path to the klog file in the other one).
Not sure if the term "raw message" is clearly defined but I hope it is understandable

Added a news entry (and also corrected the path to the klog file in the other one). Not sure if the term "raw message" is clearly defined but I hope it is understandable

Yelninei changed title from ~~WIP: system-log: Handle raw kernel messages.~~ to system-log: Handle raw kernel messages.

2025-10-19 17:39:31 +02:00

civodul requested changes

2025-10-19 18:08:53 +02:00

civodul left a comment

Nitpicking on the NEWS but otherwise LGTM! (Let me know if you prefer me to make these changes on your behalf.)

Nitpicking on the `NEWS` but otherwise LGTM! (Let me know if you prefer me to make these changes on your behalf.)

NEWS

 @ -68,2 +68,3 @@
 as can be seen with /dev/kmsg on the Hurd.
 as can be seen with /dev/klog on the Hurd.
 **  ‘system-log’ service supports raw messages from the kernel log

s/supports .*/correctly identifies messages from the kernel log/

NEWS

 @ -70,0 +71,4 @@
    (<https://codeberg.org/shepherd/shepherd/issues/46>)
 When the ‘system-log’ service encounters a message without facility information
 from the kernel log it will now treat it as a kernel message.

s/it will now treat it/, it now treats it as a kernel message, prefixing it appropriately in the log./

NEWS

 @ -70,0 +72,4 @@
 When the ‘system-log’ service encounters a message without facility information
 from the kernel log it will now treat it as a kernel message.
 This is the case with kernel messages from /dev/klog on the Hurd.

Missing newline.

Yelninei commented

2025-10-19 18:18:38 +02:00

@civodul wrote in #67 (comment):

Nitpicking on the NEWS but otherwise LGTM! (Let me know if you prefer me to make these changes on your behalf.)

I'd be fine with you adjusting the NEWS as you see fit.

@civodul wrote in https://codeberg.org/shepherd/shepherd/pulls/67#issuecomment-7803062: > Nitpicking on the `NEWS` but otherwise LGTM! (Let me know if you prefer me to make these changes on your behalf.) I'd be fine with you adjusting the NEWS as you see fit.

👍 1

civodul manually merged commit 53843384a4 into main

2025-10-19 18:38:32 +02:00

Yelninei referenced this pull request from guix/artwork

2026-02-08 11:51:31 +01:00

website: Add blog post about the 64-bit Hurd. #49

Sign in to join this conversation.

No reviewers