Previously, if given an absolute path, we would open the file, but when given a
relative path, we'd attempt to search the directories. If the user wants to open
a file from the search path, allowing paths is very confusing. E.g. with a path
like 'sysusers/foo.conf', we'd try to open '/etc/sysusers.d/sysusers/foo.conf',
'/run/sysusers.d/sysusers/foo.conf', …, and with '../foo.conf', we'd try to open
'/etc/sysusers.d/../foo.conf', '/run/sysusers.d/../foo.conf', …. This just isn't
useful, and in fact for a scheme like sysusers.d and tmpfiles.d where there we
have a flat directory with config files, only searching for plain names can
result in success. When a user specifies a relative path, it's more likely that
they wanted to open some local file. OTOH, to correctly open a local file, e.g.
one that they're just writing, this interface is also awkward, because something
like '$PWD/file.conf' has to be used to open a file with a relative path.
This patch changes the interface so that any path (i.e. an argument with "/") is
used to open a file directly, and only plain basenames are used for searching.
(Note that tpmfiles and sysusers are somewhat special here: their "config files"
make sense without the other config and users are likely to want to test them
without the other config. I was trying to do just that when writing a spec file
for a package and attempting to convert the existing scripts to sysusers and
tmpfiles. The same logic wouldn't apply for example to units or udev rules,
because they generally can only be interpreted with the whole rest of config
also available.)
I was annoyed that systemd-sysusers doesn't print any info when it opens a
config file. Its read_config_file() started out the same as the one in tmpfiles,
and then they diverged. The one in tmpfiles has that logging, hence the rework
to use it here too and get better logging. The two programs should provide
similar functionality, so using a common helper will make it easier to extend
them in tandem later.
No functional change apart from the log info.
The userdata argument (Context) is moved to the last position as requested in
the review.
a3451c2c4c added offline uid/gid support in a way
where the <root>/etc/passwd and <root>/etc/group would be read anew for each
configuration file that was parsed. The result would always be the same, so I
assume that this was an oversight. Let's use a global cache and and read the
file just once.
I was trying to run sysusers --replace, but the input file didn't have the right
suffix, and the message was very confusing. Let's split the message in two to
make it clearer that we care about the extension.
Since 2e106312e2 the test unit fails with 'resources' result instead of
'exit-code', which the test didn't account for when running unprivileged.
Before 2e106312e2:
$ /root/systemd/build/test-path
Failed to start transient scope unit: Interactive authentication required.
Couldn't allocate a scope unit for this test, proceeding without.
...
-.slice: Failed to enable/disable controllers on cgroup /user.slice/user-1000.slice/session-1.scope, ignoring: Permission denied
app.slice: Failed to create cgroup /user.slice/user-1000.slice/session-1.scope/app.slice: Permission denied
-.slice: Failed to enable/disable controllers on cgroup /user.slice/user-1000.slice/session-1.scope, ignoring: Permission denied
app.slice: Failed to create cgroup /user.slice/user-1000.slice/session-1.scope/app.slice: Permission denied
...
line 151: path-exists.path: state = running; result = success (left: 29986250)
line 151: path-exists.service: state = start; result = success
path-exists.service: Main process exited, code=exited, status=219/CGROUP
path-exists.service: Failed with result 'exit-code'.
line 151: path-exists.path: state = running; result = success (left: 29985948)
line 151: path-exists.service: state = failed; result = exit-code
Failed to start service path-exists.service, aborting test: failed/exit-code
After 2e106312e2:
$ /root/systemd/build/test-path
Failed to start transient scope unit: Interactive authentication required.
Couldn't allocate a scope unit for this test, proceeding without.
...
-.slice: Failed to enable/disable controllers on cgroup /user.slice/user-1000.slice/session-1.scope, ignoring: Permission denied
app.slice: Failed to create cgroup /user.slice/user-1000.slice/session-1.scope/app.slice: Permission denied
-.slice: Failed to enable/disable controllers on cgroup /user.slice/user-1000.slice/session-1.scope, ignoring: Permission denied
app.slice: Failed to create cgroup /user.slice/user-1000.slice/session-1.scope/app.slice: Permission denied
path-exists.service: Failed to spawn executor: No such file or directory
path-exists.service: Failed to spawn 'start' task: No such file or directory
path-exists.service: Failed with result 'resources'.
The kernel-tools meta-package was retired in Rawhide, but its
replacement has not landed, yet. Until that happens, let's build without
the bpf-framework stuff.
Let's allow configuring the debug tty independently of enabling/disabling
the debug shell. This allows mkosi to configure the correct tty while
leaving enabling/disabling the debug tty to the user.
So the field contains simply the full name of the command being invoked,
hence rename the field to match the contents, and to mirror the
"short_identifier" field.
Interestingly, the field is apparently not actually used by anything
though! But we are not going to remove it, since a follow-up commit will
start making use of it.
Prompted by https://github.com/systemd/systemd/pull/30085#discussion_r1401534107.
Note, like Reconfigure bus method, even reconfiguration for an interface is
triggered by Reload method, the method only wait for the link enters
configuring state (or unmanaged state if no matching .network file exists).
Users still need to invoke systemd-networkd-wait-online if it is
necessary to wait for the interface enters configured state after Reload
medhod.
As described in https://github.com/systemd/systemd/issues/31235, the preset
state for systemd-homed-activate.service was unclear. On the one hand, we have
a preset with 'enable systemd-homed.service', and systemd-homed.service has
'Also=systemd-homed-activate.service systemd-homed-firstboot.service', so
'preset systemd-homed.service' would also enable those two services, but
'preset systemd-homed-activate.service' would disable it, because the presets
don't say it is enabled. It seems that this configuration is internally
inconsistent. As described in the issue, maybe systemctl should be smarter
here, or warn about such configs. Either way, let's make our config consistent.
Follow-up for d1f6e01e47 and
3ccadbce33.
This new mode copies resources provided by the client, so that they
remain available for inspect/detach even if the original images are
deleted, but symlinks the profile as that is owned by the OS, so that
updates are automatically applied.
The intro of systemd-firstboot is rewritten to make it clearer how it fits into
the big picture. Systemd does some machine-id and presets and
systemd-firstboot.service is used to interactively fill in the blanks.
Closes#22225.
