journald is unable to attribute messages incoming from processes that exited to their cgroup, due to /proc vs SCM_CREDS race · Issue #2913 · systemd/systemd
changed the title
`journalctl --user-unit=...` is missing log lines
journald is unable to attribute messages incoming from processes that exited to their cgroup, due to /proc vs SCM_CREDS race
iaguis added a commit to kinvolk/rkt that referenced this issue
May 17, 2016
There's a race[1][1] on systemd that causes the systemd unit name not getting written to the journal for short-lived non-root services. To provide a way to identify an app within a pod in the logs, we set `SyslogIdentifierp` to the app name as a workaround. This causes processes forked by the app and pre/post start hooks to be identified as the app, but it was already happening before we removed appexec[2][2] with the binary exec'd by the app instead of the app name. In theory we could remove that and we'll get the binary name of each process executed in the pod as the syslog identifier, but then this workaround would not *work*. Setting the app name as the identifier is already an improvement over the previous situation. [1]: systemd/systemd#2913 [2]: rkt#2493
iaguis added a commit to kinvolk/rkt that referenced this issue
May 17, 2016
There's a race[1][1] on systemd that causes the systemd unit name not getting written to the journal for short-lived non-root services. To provide a way to identify an app within a pod in the logs, we set `SyslogIdentifierp` to the app name as a workaround. This causes processes forked by the app and pre/post start hooks to be identified as the app, but it was already happening before we removed appexec[2][2] with the binary exec'd by the app instead of the app name. In theory we could remove that and we'll get the binary name of each process executed in the pod as the syslog identifier, but then this workaround would not *work*. Setting the app name as the identifier is already an improvement over the previous situation. [1]: systemd/systemd#2913 [2]: rkt#2493
tmrts added a commit to tmrts/rkt that referenced this issue
May 25, 2016
There's a race[1][1] on systemd that causes the systemd unit name not getting written to the journal for short-lived non-root services. To provide a way to identify an app within a pod in the logs, we set `SyslogIdentifierp` to the app name as a workaround. This causes processes forked by the app and pre/post start hooks to be identified as the app, but it was already happening before we removed appexec[2][2] with the binary exec'd by the app instead of the app name. In theory we could remove that and we'll get the binary name of each process executed in the pod as the syslog identifier, but then this workaround would not *work*. Setting the app name as the identifier is already an improvement over the previous situation. [1]: systemd/systemd#2913 [2]: rkt#2493
lucaswerkmeister added a commit to lucaswerkmeister/git that referenced this issue
Jan 22, 2018
Several options imply --syslog, without there being a way to disable it again. This commit adds that option. This is useful, for instance, when running `git daemon` as a systemd service with --inetd. systemd connects stderr to the journal by default, so logging to stderr is useful. On the other hand, log messages sent via syslog also reach the journal eventually, but run the risk of being processed at a time when the `git daemon` process has already exited (especially if the process was very short-lived, e.g. due to client error), so that the journal can no longer read its cgroup and attach the message to the correct systemd unit. See systemd/systemd#2913 [1]. [1]: systemd/systemd#2913 Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de>
gitster added a commit to git/git that referenced this issue
Feb 6, 2018
This new option can be used to override the implicit --syslog of --inetd, or to disable all logging. (While --detach also implies --syslog, --log-destination=stderr with --detach is useless since --detach disassociates the process from the original stderr.) --syslog is retained as an alias for --log-destination=syslog. --log-destination always overrides implicit --syslog regardless of option order. This is different than the “last one wins” logic that applies to some implicit options elsewhere in Git, but should hopefully be less confusing. (I also don’t know if *all* implicit options in Git follow “last one wins”.) The combination of --inetd with --log-destination=stderr is useful, for instance, when running `git daemon` as an instanced systemd service (with associated socket unit). In this case, log messages sent via syslog are received by the journal daemon, but run the risk of being processed at a time when the `git daemon` process has already exited (especially if the process was very short-lived, e.g. due to client error), so that the journal daemon can no longer read its cgroup and attach the message to the correct systemd unit (see systemd/systemd#2913 [1]). Logging to stderr instead can solve this problem, because systemd can connect stderr directly to the journal daemon, which then already knows which unit is associated with this stream. [1]: systemd/systemd#2913 Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Lucas Werkmeister <mail@lucaswerkmeister.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
olysonek added a commit to InfrastructureServices/vsftpd that referenced this issue
Jun 18, 2018
Pass messages given to die(), die2() and bug() to syslog. Currently this functionality requires waiting for a short amount of time (1 second is used) after logging the message and before exiting. This is a workaround for the following systemd bug: systemd/systemd#2913 The need for this workaround is the main reason why I decided not to enable this functionality by default. Resolves: rhbz#1318198 Resolves: rhbz#1582672
carlwgeorge pushed a commit to iusrepo/git222 that referenced this issue
Jun 9, 2019
Using stderr rather than syslog should be a mild improvement with the
systemd journal. The reasons are detailed in the upstream commit
0c591cacba ("daemon: add --log-destination=(stderr|syslog|none)",
2018-02-04)¹:
The combination of --inetd with --log-destination=stderr is useful, for
instance, when running `git daemon` as an instanced systemd service
(with associated socket unit). In this case, log messages sent via
syslog are received by the journal daemon, but run the risk of being
processed at a time when the `git daemon` process has already exited
(especially if the process was very short-lived, e.g. due to client
error), so that the journal daemon can no longer read its cgroup and
attach the message to the correct systemd unit (see systemd/systemd#2913
[1]). Logging to stderr instead can solve this problem, because systemd
can connect stderr directly to the journal daemon, which then already
knows which unit is associated with this stream.
[1]: systemd/systemd#2913
While here, wrap the git-daemon command line to improve readability.
¹ git/git@0c591ca
This was referenced
May 4, 2020