Optional syslog support #1590

troglobit · 2025-01-08T06:12:13Z

This pull request adds an optional syslog backend alternative to the default stdout/stderr logging. It is primarily intended for systems using RAUC without systemd, e.g., an embedded system built around BusyBox init.

It is of course possible to use RAUC as-is on non-systemd systems, however with this patch users avoid ANSI escape sequences (color) in their logs and can perform severity based filtering for remote logging of critical events.

We use an earlier version of this patch in the Infix NOS. This updated version adds configurable facility support and also ensures to replace the default logger.

codecov · 2025-01-08T10:54:34Z

Codecov Report

Attention: Patch coverage is 84.61538% with 6 lines in your changes missing coverage. Please review.

Project coverage is 84.51%. Comparing base (e6b6152) to head (1e16869).

Files with missing lines	Patch %	Lines
src/main.c	84.61%	6 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1590   +/-   ##
=======================================
  Coverage   84.51%   84.51%           
=======================================
  Files          76       76           
  Lines       22384    22423   +39     
=======================================
+ Hits        18917    18950   +33     
- Misses       3467     3473    +6

Flag	Coverage Δ
service=false	`80.86% <0.00%> (-0.15%)`	⬇️
service=true	`84.46% <84.61%> (+<0.01%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

jacmet · 2025-01-08T12:43:41Z

LGTM, it would indeed be handy to have rather than having to pipe rauc stdout/sterr to logger

jluebbe

Since 2.80, glib has native support for syslog. Currently, we only require glib 2.56. Furthermore, the glib implementation defaults to the "user" facility (if not overridden on the message level). So we can't easily use the native support.

Still, we could take some inspiration from the implementation, such as avoiding the need for SYSLOG_NAMES by mapping to the integer levels directly.

Which use-case do you see for specifying the facility on the command line? Perhaps hard-coding it to the LOG_DAEMON value would be enough?

jluebbe · 2025-01-08T13:59:53Z

src/main.c

+		}
+	}
+
+	openlog(G_LOG_DOMAIN, LOG_PID | LOG_NOWAIT, facility);


syslog(3) mentions that LOG_NOWAIT has no effect on Linux, so it could be removed.

Well, it depends a bit on the backend. I maintain sysklogd, which today supplies an RFC5424 compliant syslogp(), as well as replacement syslog() API, this is one implementation that can replace the stanard C-library APIs for syslog.

There's no overhead to supporting LOG_NOWAIT, but if you only want to support GLIBC or standard C-library, that is fine and I can remove it.

What's the effect of LOG_NOWAIT with sysklogd?

Internally it will connect immediately to the /dev/log socket instead of postponing it until the first syslog() call.

jluebbe · 2025-01-08T14:01:59Z

src/main.c

 #include <locale.h>
 #include <stdio.h>
 #include <string.h>
+#define SYSLOG_NAMES


Is this really needed? https://sourceware.org/bugzilla/show_bug.cgi?id=16355 sounds like we should avoid this define.

The define opens up the use of facilitynames[]. It has been a long standing practice, but we can replace that with a local array of the same names if you want.

troglobit · 2025-01-08T14:31:58Z

@jluebbe I take it you are still overall in favor of adding native syslog() support in this form? Or would you prefer closing this in favor of the native (later) glib support? I'm fine either way, we can carry the patch locally until we get the bump in glib version.

jluebbe · 2025-01-08T14:48:42Z

@jluebbe I take it you are still overall in favor of adding native syslog() support in this form? Or would you prefer closing this in favor of the native (later) glib support? I'm fine either way, we can carry the patch locally until we get the bump in glib version.

To fully replace this native implementation with the glib feature, we'd need to add a way to set the default facility via the glib API, which would result in an even higher minimum version. So I'm still in favor of a native implementation.

It would be good to have test coverage for the new code, so that we can avoid regressions. Can we temporarily run a syslog service to catch messages from rauc running with --syslog?

jacmet · 2025-01-08T15:43:06Z

To fully replace this native implementation with the glib feature, we'd need to add a way to set the default facility via the glib API, which would result in an even higher minimum version. So I'm still in favor of a native implementation.

glib 2.80 is also quite recent (~10 months ago), so it would be annoying to require it

troglobit · 2025-01-09T06:42:50Z

@jluebbe I take it you are still overall in favor of adding native syslog() support in this form? Or would you prefer closing this in favor of the native (later) glib support? I'm fine either way, we can carry the patch locally until we get the bump in glib version.

To fully replace this native implementation with the glib feature, we'd need to add a way to set the default facility via the glib API, which would result in an even higher minimum version. So I'm still in favor of a native implementation.

OK, cool thanks!

It would be good to have test coverage for the new code, so that we can avoid regressions. Can we temporarily run a syslog service to catch messages from rauc running with --syslog?

Should definitely be possible. I'll have a look at your regression test system and see what I can do.

jluebbe · 2025-06-25T15:56:45Z

@troglobit Do you need some help for the testing side? If that's blocking you, we could try to find some time to prepare something there.

troglobit · 2025-06-26T05:25:11Z

@troglobit Do you need some help for the testing side? If that's blocking you, we could try to find some time to prepare something there.

Sorry for dragging my feet on this one, I've been reassigned to other projects for a while. Been meaning to get back to this, and possibly in a week or two, now that Sweden is shutting down for the summer, I'll be back on it. If I get stuck, I'll let you know, thanks!

This patch adds an optional syslog backend alternative to the default stdout/stderr logging. The syslog backend is enabled with `--syslog` on the command line. It logs directly to the local syslog daemon, via the POSIX syslog() API, using a default 'daemon' facility. This facility can be changed if an optional argument is given, e.g., `--syslog=local0`. Useful for basic message filtering to a dedicated log file. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

This new test verifies syslog support by creating a dummy listener for the /dev/log socket and checking the log format sent to this socket to ensure it contains rauc[PID]: style logs like 'service start'. Three different variations, for maximum coverage, are run: --syslog (no argument, default facility) --syslog=local0 (custom facility, should pass OK) --syslog=undefined (invalid facility, should FAIL) Note, test is skipped if /dev/log already exists or if it cannot bind the domain socket to /dev/log. Either a syslog daemon is running, a case the test is not designed for, or the test is running in a cross environment without podman being started with --privileged. Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

troglobit · 2025-07-21T14:30:42Z

There, finally some tests for the syslog backend! I hope they meet your expectations.

Note, the test relies on the standard libc syslog() API, which writes to /dev/log. So the test sets up a UNIX socket and tries to bind it to /dev/log, if this fails, as it does on the cross tests because of non-privileged mode of podman, then the test is skipped. Otherwise the test emulates a syslog daemon and starts the rauc service with different options to verify the intended behavior.

troglobit · 2025-09-15T15:15:19Z

Ping 🔔 I hope this meets your expectations, @jluebbe 😃

edmundoferreira · 2025-10-31T16:27:09Z

troglobit really nice feature, this would be really helpful.

I do have one question though:

How will this rauc -s option play with rauc system.conf [log.<logger>] section?

It overrides the system.conf filename?
Can I specify this in my system.conf instead, to have syslog integration insteading of passing -s all the time? if yes how?

ejoerns added the enhancement Adds new functionality or enhanced handling to RAUC label Jan 8, 2025

jluebbe self-requested a review January 8, 2025 13:39

jluebbe reviewed Jan 8, 2025

View reviewed changes

troglobit marked this pull request as draft January 9, 2025 13:12

troglobit changed the title ~~RFC: Optional syslog support~~ Optional syslog support Jan 9, 2025

jluebbe assigned troglobit Jan 21, 2025

troglobit marked this pull request as ready for review July 21, 2025 10:57

troglobit force-pushed the syslog-support branch from 0889f58 to a4e500c Compare July 21, 2025 11:07

troglobit marked this pull request as draft July 21, 2025 11:30

troglobit force-pushed the syslog-support branch 3 times, most recently from 3d0656b to ea64b4c Compare July 21, 2025 12:43

troglobit force-pushed the syslog-support branch from ea64b4c to 1e16869 Compare July 21, 2025 14:10

troglobit marked this pull request as ready for review July 21, 2025 14:23

troglobit requested a review from jluebbe July 21, 2025 14:23

troglobit mentioned this pull request Sep 15, 2025

Upstream rauc patches kernelkit/infix#834

Open

Optional syslog support #1590

Are you sure you want to change the base?

Optional syslog support #1590

Conversation

troglobit commented Jan 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Jan 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

jacmet commented Jan 8, 2025

Uh oh!

jluebbe left a comment

Choose a reason for hiding this comment

Uh oh!

jluebbe Jan 8, 2025

Choose a reason for hiding this comment

Uh oh!

troglobit Jan 8, 2025

Choose a reason for hiding this comment

Uh oh!

jluebbe Jan 8, 2025

Choose a reason for hiding this comment

Uh oh!

troglobit Jan 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jluebbe Jan 8, 2025

Choose a reason for hiding this comment

Uh oh!

troglobit Jan 8, 2025

Choose a reason for hiding this comment

Uh oh!

troglobit commented Jan 8, 2025

Uh oh!

jluebbe commented Jan 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jacmet commented Jan 8, 2025

Uh oh!

troglobit commented Jan 9, 2025 • edited by jluebbe Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jluebbe commented Jun 25, 2025

Uh oh!

troglobit commented Jun 26, 2025

Uh oh!

troglobit commented Jul 21, 2025

Uh oh!

troglobit commented Sep 15, 2025

Uh oh!

edmundoferreira commented Oct 31, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

troglobit commented Jan 8, 2025 •

edited

Loading

codecov bot commented Jan 8, 2025 •

edited

Loading

troglobit Jan 9, 2025 •

edited

Loading

jluebbe commented Jan 8, 2025 •

edited

Loading

troglobit commented Jan 9, 2025 •

edited by jluebbe

Loading