[systemd-devel] Confusing Output of "journalctl --setup-keys --force"

[Lennart Poettering]

On Di, 23.02.21 22:14, Andreas Krüger (DrAndreasKrueger at web.de) wrote:

>    developer at debianVM ~ % sudo
>    /home/developer/scb/LoggerDaemon_1st/scb/scb/logger_daemon/build/cmake.debug.linux.x86_64/logger_daemon
>    err:
>    Generating seed...
>    Generating key pair...
>    err:
>    Generating sealing key...
>    err:
>    Failed to set file attributes: Operation not supported
>    std:
>    72aa1f-825856-6d408b-4308bb/1b5da7-35a4e900
>
>    This means that 4 lines where posted by stderr (err:)  and 1 line by
>    stdout (std:).
>
>    Now my questions:
>      * What's about the rest of lines? Where do they come from, when
>        executing it directly? Why are those lines not output, when executing
>        the journal command by my program? (I know, you don't know my program,
>        so you can assume that it is just goes badly, but actually it has
>        worked in combination with other commands pretty well so
>    far...)

We log what we currently do to stderr, which is how this is done on
UNIX, i.e. stderr is the place for error messages, status messages and
such.

We log the actual relevant *contents* data to stdout, i.e. in this
case the verification key, because that is the data the program
actually is supposed to generate, and just meta info about how and
when it is doing so.

The fact that these are two distinct data streams makes shell file
redirection nice and easy. If you want just the key you can do

    journalctl --setup-keys > my-verification-key.txt

And you still get some info to you tty what we are doing, but the key
you wanted to generate ends up in the file where it should be.

We detect if redirection is used and suppress some explanatory
comments in the output, since they are unlikely to be useful when
piping things to files or shell pipelines.

>      * The first 4 lines are output via stderr, even though only the last one
>        seems to be a real error message. What's the intension to post the
>        first 3 line via stderr? Even though the error message is posted,
>        everything seems fine, since the return value at the end is 0. So,
>        what's going on here? Was the program really executed correctly?

As mentioned, on UNIX "stderr" is a bit of a misnomer, it's not just
where error messages go, but any kind of status log messages, that
tell you what the tool is doing.

You can turn off logging if you like by setting
SYSTEMD_LOG_TARGET=null if you like. In that case all log output is
suppressed and you'll only see the actual output being generated.

Lennart

--
Lennart Poettering, Berlin