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
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).
In varlink.c we generally do not make failing callback functions fatal,
since that should be up to the app. Hence, in case of varlinkctl (where
we want failures to be fatal), make sure to propagate the error back
explicitly.
Before this change a failing call to "varlinkctl --more call …" would result in
a zero exit code. With this it will correctly exit with a non-zero exit
code.
When running in LXC with AppArmor we'll most likely get an error when creating
a network namespace due to a kernel regression in < v6.2 affecting AppArmor,
resulting in denials. Like other tests, avoid failing in case of permission
issues and handle it gracefully.
Typically, soft-reboot.target is never reached. So, without this change,
systemd-journald may be killed by PID1 on soft-reboot, and may cause
journal corruption.
This reverts commit 4263d7617f.
Still I think this is the way to go. But the change was merged after -rc2,
and still discussion is continued. So, at least now let's revert it,
and do that after v256-final is released if approved.