For run0 (as opposed to systemd-run in general), connecting to
the system bus (of localhost or container) as a different user
than root and then trying to elevate privilege from that
makes little sense:
https://github.com/systemd/systemd/issues/32997#issuecomment-2127992973
The @ syntax is mostly useful when connecting to the user bus,
which is not a use case for run0. Hence, let's remove the example.
The syntax will be properly refused in #32999.
"journalctl -u foo.service" may not work as expected, especially entries
for _TRANSPORT=stdout, for short-living services or when the service manager
generates debugging logs. Instead, SYSLOG_IDENTIFIER= should be reliable for
stdout. Let's use it.
An example case:
```
__CURSOR=s=06278e3bf011458e973c81d370a8f7a5;i=1e4dc;b=1b0258a5c78341609bf462c72d4541c3;m=308de65;t=6194c3895a13f;x=50c7e9af5b8cfc37
__REALTIME_TIMESTAMP=1716665017803071
__MONOTONIC_TIMESTAMP=50912869
_BOOT_ID=1b0258a5c78341609bf462c72d4541c3
SYSLOG_FACILITY=3
_UID=0
_GID=0
_MACHINE_ID=d3490e076ab24968bfa19a6aab26beb3
_HOSTNAME=H
_RUNTIME_SCOPE=system
_TRANSPORT=stdout
PRIORITY=6
_PID=2668
_STREAM_ID=3f9b8855636041988d003a9c63379b8a
SYSLOG_IDENTIFIER=echo
MESSAGE=foo
```
As you can see, there is no unit identifier.
Follow-up for 14631951ce
Before this commit, if WorkingDirectory= is empty or literally "-",
'simplified' is not populated, resulting in the ASSERT_PTR
in unit_write_settingf() below getting triggered.
Also, do not accept "-", so that the parser is consistent
with load-fragment.c
Fixes#33015
After soft-reboot, /var/log/journal may be initially read-only,
and becomes writable a bit later. In such case, runtime journal is
initially opened by journald. Hence, we need to flush to /var when it is
ready.
If the runtime journal is opened, we will anyway write journal entries
to the runtime journal, even if the persistent journal is writable.
Hence, we need to flush the runtime journal file later.
So, we need to try to read timezone several times.
Also, on failure, show journal of timedated instead of hostnamed,
as the timezone is handled by timedated.
Hopefully fixes#33007.
If an initrd has an empty or uninitialized /etc/machine-id file,
then PID1 write a valid machine ID. So, the logic is important only on
soft-reboot. Let's mention that explicitly.
Follow-up for 16718dcf78.
- mention that /run/machine-id is used if exist.
- mention system.machine_id credential,
- credential, VM uuid, and container uuid are not read when --root=
is specified or running in a chroot environment.
This effectively reverts ba540e9f1c.
https://github.com/systemd/systemd/pull/32915#discussion_r1608258136
> In many cases we allow --root=/ as a mechanism for forcing an "offline" mode,
> while still operating on the root dir. if we do the getenv_for_pid() thing
> below I'd claim this is very much an "online" operation, and hence --root=/
> should really disable that.
Before:
/etc/kernel/install.conf:6: Unknown key name 'asdf' in section '(null)', ignoring.
After:
/etc/kernel/install.conf:6: Unknown key 'asdf', ignoring.
Also make the message a bit better.
If both literal and signed PCR bindings are not used then we won't
determine a PCR bank to use, and hence we shouldnt attempt to serialize
it either.
Hence, if the bank is zero, skip serialization.
(And while we are at it, also skip serialization of the primary
algorithm if not set, purely to make things systematic).
[This effectively results in little change, as previously we'd then
seralize a json "null", while now we simply won't genreate the field]
We so far derived the PCR bank to use from the PCR values specified fr
literal PCR binding. However, when that's not used then we left the bank
uninitialized – which will break if signed PCR binds are used (where we
need to pick a bank too after all).
Hence, let's explicitly pick a bank to use if literal PCR values are not
used, to make things just work.
Fixes: #32946
We want to avoid reinitialization of our global variables with static
storage duration in case we get dlopened multiple times by the same
application. This will avoid potential resource leaks that could have
happened otherwise (e.g. leaking journal socket fd).
