Systemd log format activable via env var

I updated my program with something along the lines of https://github.com/rust-cli/env_logger/blob/main/examples/syslog_friendly_format.rs to have a systemd friendly logging, however when I use other binaries using env_logger usually the same logic is not available, can we have it enable-able by default in env_logger?

ie if RUST_LOG_STYLE=SYSTEMD the default formatting is changed with the systemd friendly one without having to change the downstream lib

specifically for systemd its quite easy to automatically detect being run as a daemon.
i am sure that its possible for other service managers/init systems too, but to the best of my knowledge systemd simply is the main one by far.

@djugei

@djugei in #357, you also mentioned the idea of having a separate format string.

What value would users get by having all of this baked into env_logger::Logger vs having a way to compose multiple loggers, including a syslog logger?

@RCasatta

defaults matter a lot. developers want to run their binaries in terminal and see timestamps, users want to run applications as daemons and see timestamps only once. people simply will not have a more complex setup.

and this is a real issue, i am sure @RCasatta has observed this in a rust application they were running, and so have i.
ofc if the app is open source we can go around and make prs for every single project.
or just one here.
the later seems like the smarter option.

Sorry, I missed read this (being used to multi-platform system logs being rendered out of band from stdout). Looking back over #358, this is just about changing the output format.

env_logger then auto-detects if its running as a daemon

I am open to auto-detection.

env_logger then auto-detects if its running as a daemon, with an override available.

I don't think we need a specific variable to control the auto-detection: we can expose a function that matches the custom format signature and people can customize things as they want.

ie if RUST_LOG_STYLE=SYSTEMD the default formatting is changed with the systemd friendly one without having to change the downstream lib

That is specific to binaries, not libraries, and I assume binaries will generally know they will be run in a daemon mode to support something like this.

#358

The format used in this was

                Box::new(|buf, record| {
                    writeln!(
                        buf,
                        "<{}>{}: {}",
                        match record.level() {
                            Level::Error => 3,
                            Level::Warn => 4,
                            Level::Info => 6,
                            Level::Debug => 7,
                            Level::Trace => 7,
                        },
                        record.target(),
                        record.args()
                    )
                })

Where is the relevant documentation for this? My initial searches come up short.

the format was literally copied from the example in this repository, after cross-checking with the relevant manpages to verify that this is actually a valid way to log to syslog. there is more valid ways, for example by providing a timestamp, but that gets auto-filled in by the syslog.
syslog format is.. semi-standardtized but that setup seems to work for journald.

I confirm I use it with systemd and it works. For example you can filter error logs via:

journalctl -u unit -p 3

the format was literally copied from the example in this repository, after cross-checking with the relevant manpages to verify that this is actually a valid way to log to syslog. there is more valid ways, for example by providing a timestamp, but that gets auto-filled in by the syslog.
syslog format is.. semi-standardtized but that setup seems to work for journald.

Was not aware of that example, thanks!

In that case, for anything we do, we should update or remove that example. We'll also need to ensure people have a good way of discovering this functionality.

I confirm I use it with systemd and it works. For example you can filter error logs via:

journalctl -u unit -p 3

just to be explicit here: you have tested #358 and it solves your usecase?

In that case, for anything we do, we should update or remove that example. We'll also need to ensure people have a good way of discovering this functionality.

i have updated the example. discoverability is not worse now, and also somewhat optional as it should just work, thats the magic of good defaults.
as mentioned in #358 (comment) please do advise where adding documentation would be useful.

I confirm I use it with systemd and it works. For example you can filter error logs via:

journalctl -u unit -p 3

just to be explicit here: you have tested #358 and it solves your usecase?

I was referring to the log format, I didn't test with #358

@djugei

@djugei what are your thoughts on the plain I laid out in #349 (comment)?

To re-summarize

Auto-detect we are running as a service and switch the format
Provide a syslog_format and ConfigurableFormat, allowing people to remove the auto-detection by passing ConfigurableFormat as a custom format, or providing their own auto-detection by wrapping syslog_format and ConfigurableFormat

The main question I have is whether we provide a syslog_format function or a SysLogFormat struct that then allows customization in the future.

@djugei

From #358 (comment)

@djugei

i kinda want to slightly alter the log format, right now syslog contains

date host processname[process_id] processname::module:: message

i would like date host processname[process_id] ::module:: message better to reduce redundancy.

i am unsure what the easiest way to get the top level binary name is though. then it would be a simple .strip_prefix(name).

i am unsure what the easiest way to get the top level binary name is though. then it would be a simple .strip_prefix(name).

If I understand correctly, you are wanting to strip processname from the target?

Looks like log gets that from std::module_path!(). So I'm guessing that the standard library is just using the crate's name in which the log operation was invoked. So it mostly looks like the process name when inside of the binary and something else when outside which means we can't simply strip the first component before ::. It won't always match argv[0] / current_exe() either because a module name can be different than a binary name (e.g. foo_bar vs foo-bar.exe). Cargo sets CARGO_CRATE_NAME but we have to be built inside the users crate to access that.

Some solutions I see include

Add a strip_crate_name builder method to SysLogFormat
- This requires manually constructing one. Maybe we could generalize this and also put it on ConfigurableFormat / Builder which will then strip it regardless of the format
Have a syslog_format!() which won't work with auto-detection
Leave this extra customization to users, like it is today

What I'm unsure of is how universal people would want this. While it is redundant, I could also see it being helpful when you have log messages coming from a variety of crates. This could also make writing of RUST_LOG filters difficult if you don't see the full target.

#349 (comment)

That seems like a sensible approach though currently i am unsure to what extent customizing the syslog format is useful.
i will rebase and rework my pr in the comming days

Leaving it to users seems reasonable. I currently just added a flag --systemd. Then when it is passed, I run:

builder.format_timestamp(None);
builder.format_target(false);

and it gets rid of the repeated logic.

Users might want slightly different variations of this.

i specifically believe that it should work by default. leaving it to the users means it won't get done or won't get done consistently. i feel like it is the task of the logging library to output log lines appropriate to the environment it runs in.

I'd like to suggest adding priority prefixes to ConfigurableFormat and handling auto deteciton in Builder.

I implemented this in #408, would be cool to hear your thoughts on this approach.

Navigation Menu

Repository navigation

Systemd log format activable via env var #349

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Systemd log format activable via env var #349

Description

Activity

djugei commented on Mar 31, 2025

epage commented on Mar 31, 2025

djugei commented on Mar 31, 2025

epage commented on Mar 31, 2025

djugei commented on Apr 1, 2025

RCasatta commented on Apr 1, 2025

epage commented on Apr 1, 2025

djugei commented on Apr 2, 2025

djugei commented on Apr 2, 2025

RCasatta commented on Apr 4, 2025

epage commented on Apr 9, 2025

epage commented on Apr 9, 2025

epage commented on Apr 9, 2025

djugei commented on Apr 17, 2025

dcampbell24 commented on Jan 18, 2026

djugei commented on Apr 28, 2026

sant0s12 commented on May 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions