We use those strings as hash keys. While writing "a...b" looks strange,
"a///b" does not look so strange. Both syntaxes would actually result in the
value being correctly written to the file, but they would confuse our
de-deplication over keys. So let's normalize. Output also becomes nicer.
Add test.
Rely on information provided by /proc/*/stat and /sys/dev/char for resolving
the controlling tty for the display server, instead of trying to access the
tty device in /dev (which may not be accessible for example due to
PrivateDevices=yes).
The tool deals with any kind of 128bit id, not just uuid, and by default
we display just a series of hex chars, hence let's not claim everything
was a "uuid", but just generically say "id"
Previously there was a weird asymmetry: initially we'd resolve the
specified prefix path when chasing symlinks together with the actual
path we were supposed to cover, except when we hit an absolute symlink
where we'd use the root as it was. Let's unify handling here: the prefix
path is never resolved, and always left as it is.
This in particular fixes issues with symlinks in the prefix path, as
that confused the check that made sure we never left the root directory.
Fixes: #14634
Replaces: #14635
```
ninja -C build
ninja: Entering directory `build'
[29/101] Generating systemd_boot.so with a custom command.
FAILED: src/boot/efi/systemd_boot.so
/usr/bin/ld -o src/boot/efi/systemd_boot.so -T /usr/lib64/gnuefi/elf_x64_efi.lds -shared -Bsymbolic -nostdlib -znocombreloc -L /usr/lib64 /usr/lib64/gnuefi/crt0-efi-x64.o src/boot/efi/disk.c.o src/boot/efi/graphics.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o src/boot/efi/boot.c.o src/boot/efi/console.c.o src/boot/efi/crc32.c.o src/boot/efi/random-seed.c.o src/boot/efi/sha256.c.o src/boot/efi/shim.c.o -lefi -lgnuefi /usr/lib/gcc/x86_64-redhat-linux/10/libgcc.a
/usr/bin/ld: src/boot/efi/graphics.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/pe.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/util.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/boot.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/console.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/random-seed.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
/usr/bin/ld: src/boot/efi/shim.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: multiple definition of `loader_guid'; src/boot/efi/disk.c.o:/home/sus/tt/systemd/build/../src/boot/efi/util.h:58: first defined here
[31/101] Generating stub.c.o with a custom command.
ninja: build stopped: subcommand failed.
make: *** [Makefile:2: all] Error 1
```
Let's lock this down a bit. Effectively nothing much changes, since the
default PK policy will allow users on the VT to change VT. Only users
with no local VT session won't be able to switch VTs.
This way we shuld be able to order mounts properly against their backing
services in case complex storage is used (i.e. LUKS), even if the device
path used for mounting the devices is different from the expected device
node of the backing service.
Specifically, if we have a LUKS device /dev/mapper/foo that is mounted
by this name all is trivial as the relationship can be established a
priori easily. But if it is mounted via a /dev/disk/by-uuid/ symlink or
similar we only can relate the device node generated to the one mounted
at the moment the device is actually established. That's because the
UUID of the fs is stored inside the encrypted volume and thus not
knowable until the volume is set up. This patch tries to improve on this
situation: a implicit After=blockdev@.target dependency is generated for
all mounts, based on the data from /proc/self/mountinfo, which should be
the actual device node, with all symlinks resolved. This means that as
soon as the mount is established the ordering via blockdev@.target will
work, and that means during shutdown it is honoured, which is what we
are looking for.
Note that specifying /etc/fstab entries via UUID= for LUKS devices still
sucks and shouldn't be done, because it means we cannot know which LUKS
device to activate to make an fs appear, and that means unless the
volume is set up at boot anyway we can't really handle things
automatically when putting together transactions that need the mount.
This catches up with 9d06297e26 and adapts
the change made to swap units. We generally don't want to react
a-posteriori to swap devices disappearing, bad things will happen
anyway.
Teaches systemd-fstab-generator these two unit options,
creating appropriate dependencies on the generated .mount
units. When used, they override any other automatically
generated dependencies, such as local-fs.target, and are
NOT suppressed by noauto. The new options are ignored for
/, in the same way that noauto is ignored.
Fixes: #14380
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
Let's remove a function of questionnable utility.
strv_clear() frees the items of a string array, but not the array
itself. i.e. it half-drestructs a string array and makes it empty. This
is not too useful an operation since we almost never need to just do
that, we also want to free the whole thing. In fact, strv_clear() is
only used in one of our .c file, and there it appears like unnecessary
optimization, given that for each array with n elements it leaves the
number of free()s we need to at O(n) which is not really an optimization
at all (it goes from n+1 to n, that's all).
Prompted by the discussions on #14605
In SecureBoot mode this is probably not what you want. As your cmdline
is cryptographically signed like when using Type #2 EFI Unified Kernel
Images (https://systemd.io/BOOT_LOADER_SPECIFICATION/) The user's
intention is then that the cmdline should not be modified. You want to
make sure that the system starts up as exactly specified in the signed
artifact.
We need to run sysctl also in containers, because the network
subtree is namespaces and may legitimately be writable. But logging
all "errors" at notice level creates unwanted noise.
Also downgrade message about missing sysctls to log_info. This might also be
relatively common when configuration is targeted at different kernel
versions. With log_debug it'll still end up in the logs, but isn't really worth
of "notice" most of the time.
https://bugzilla.redhat.com/show_bug.cgi?id=1609806
This extends on d253a45e1c, and instead of
merging just a single flag from previous mount entries of
/proc/self/mountinfo for the same path we merge all three.
This shouldn't change behaviour, but I think make things more readable.
Previously we'd set MOUNT_PROC_IS_MOUNTED unconditionally, we still do.
Previously we'd inherit MOUNT_PROC_JUST_MOUNTED from a previous entry on
the same line, we still do.
MOUNT_PROC_JUST_CHANGED should generally stay set too. Why that? If we
have two mount entries on the same mount point we'd first process one
and then the other, and the almost certainly different mount parameters
of the two would mean we'd set MOUNT_PROC_JUST_CHANGED for the second.
And with this we'll definitely do that still.
This also adds a comment explaining the situation a bit, and why we get
into this situation.
This changes nss-systemd to use the new varlink user/group APIs for
looking up everything.
(This also changes the factory /etc/nsswitch.conf line to use for
hooking up nss-system to use glibc's [SUCCESS=merge] feature so that we
can properly merge group membership lists).
Fixes: #12492
This way we can use libxcrypt specific functionality such as
crypt_gensalt() and thus take benefit of the newer algorithms libxcrypt
implements. (Also adds support for a new env var $SYSTEMD_CRYPT_PREFIX
which may be used to select the hash algorithm to use for libxcrypt.)
Also, let's move the weird crypt.h inclusion into libcrypt.h so that
there's a single place for it.
Previously we'd allow marking TTY sessions as idle, but when the user
tried to unmark it as idle again it we'd just revert to automatic TTY
atime idle detection, thus making it impossible to mark the session as
non-idle, unless its TTY is atime-touched all the time. But of course,
marking a session as idle is pretty much fatal if you never can mark it
as non-idle again.
This change is triggred by bug reports such as this:
https://github.com/systemd/systemd/issues/14053
With this patch we will now output a clean, clear error message if a
client tries to manipulate the idle state of a non-graphical session.
This means we now have clear rules: "manual" idle logic for graphical
sessions, and TTY based ones for all others that have a TTY of some
form.
I considered allowing the idle state to be overriden both ways for tty
sessions but that's problematic: for sessions that are temporarily
upgraded from tty to graphical and thus suddenly want to manage their
own idle state we'd need to a way to detect when the upgrade goes away
and thus we should revert to old behaviour. Without reverting to the
previous TTY idle auto-magic we'd otherwise be stuck in an eternally
idle or eternally non-idle state, with really bad effects in case
auto-suspend is used. Thus, let's instead generate a proper error
message, saying clearly we don't support it.
(Also includes some other fixes and clean-ups in related code)
Closes: #14053
We'd just print nothing and exit with 0. If the user gave an explicit
name, we should fail. If a pattern didn't match, we should at least warn.
$ networkctl status enx54ee75cb1dc0a* --no-pager && echo $?
No interfaces matched.
0
$ networkctl status enx54ee75cb1dc0a --no-pager
Interface "enx54ee75cb1dc0a" not found.
1
When starting a mount unit, systemd invokes mount command and moves the
unit's internal state to "mounting". Then it watches for updates of
/proc/self/mountinfo. When the expected mount entry newly appears in
mountinfo, the unit internal state is changed to "mounting-done".
Finally, when systemd finds the mount command has finished, it checks
whether the unit internal state is "mounting-done" and changes the state
to "mounted".
If the state was not "mounting-done" in the last step though mount command
was successfully finished, the unit is marked as "failed" with following
log messages:
Mount process finished, but there is no mount.
Failed with result 'protocol'.
If daemon-reload is done in parallel with starting mount unit, it is
possible that things happen in following order and result in above failure.
1. the mount unit state changes to "mounting"
2. daemon-reload saves the unit state
3. kernel completes the mount and /proc/self/mountinfo is updated
4. daemon-reload restores the saved unit state, that is "mounting"
5. systemd notices the mount command has finished but the unit state
is still "mounting" though it should be "mounting-done"
mount_setup_existing_unit() should take into account that MOUNT_MOUNTING
is transitional state and set MOUNT_PROC_JUST_MOUNTED flag if the unit
comes from /proc/self/mountinfo so that mount_process_proc_self_mountinfo()
later can make state transition from "mounting" to "mounting-done".
Fixes: #10872
Primarily, use the new multi-line support in table formatting.
Also, stream-line naming of the "max-addresses" options. We used three
names for the concept internall, let's just unify on the name we use for
this for external users, i.e. "max-addresses".
In subsequent commits, calls to if_nametoindex() will be replaced by a wrapper
that falls back to alternative name resolution over netlink. netlink support
requires libsystemd (for sd-netlink), and we don't want to add any functions
that require netlink in basic/. So stuff that calls if_nametoindex() for user
supplied interface names, and everything that depends on that, needs to be
moved.
We don't need a seperate output parameter that is of type int. glibc() says
that the type is "unsigned", but the kernel thinks it's "int". And the
"alternative names" interface also uses ints. So let's standarize on ints,
since it's clearly not realisitic to have interface numbers in the upper half
of unsigned int range.
If we have a template unit template@.service, it should be allowed to specify a
dependency on a unit without an instance, bar@.service. When the unit is created,
the instance will be propagated into the target, so template@inst.service will
depend on bar@inst.service.
This commit changes unit_dependency_name_compatible(), which makes the manager
accept links like that, and unit_file_verify_alias(), so that the installation
function will agree to create a symlink like that, and finally the tests are
adjusted to pass.
It might be needed to follow symlinks more deeply when we're looking for
enablement symlinks pointing to the removed service.
Let's consider the case where service 'old' is being renamed 'new' (will happen
most likely during package upgrade). Before the service is going to be renamed,
there's the following enablement symlink:
/etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service
In order to rename 'old' into 'new' and transparently restart the service, the
old name is still provided as a 'static' alias for the new service. This should
also help keeping backward compatibilities since the old name might still be
embedded in unit files, scripts, generators and such.
Hence after the package is upgraded, the following symlinks including the
enablement symlink are present:
/usr/lib/systemd/system/old.service -> new.service
/etc/systemd/system/multi-user.target.wants/old.service -> /usr/lib/systemd/system/old.service
If later the user decides to disable the service, we should figure out that the
enablement symlink (which still has the old name) is actually referring to 'new'
(indirectly) even if it points to the alias.
This mostly reuses existing checkers used by pid1, so handling of aliases
should be consistent. Hopefully, with the test it'll be clearer what it
happening.
Support for .wants/.requires "aliases" is restored. Those are still used in the
wild quite a bit, so we need to support them.
See https://github.com/systemd/systemd/pull/13119 for a discussion of aliases
with an instance that point to a different template: this is allowed.
Will print a unit and all of its dependencies. Works with cat, status,
list-units, and list-unit-files. This flag can also be used in conjunction
with --reverse, --before, and --after.
We also vastly simplify the list_dependencies_get_dependencies logic.
Instead of using 5 strvs and merging them into one, use one strv and
have the bus append all the map values to it.
Fixes#9273
Interfaces may come up at any time, even during our initialization of
them, for various reasons; e.g. the kernel will raise VLAN when its
parent is raised; or we will raise an interface if configured with
BindCarrier and its associated interfaces come up.
When LinkLocalAddressing has been disabled for ipv6, we disable
addr_gen_mode in the kernel, so it will not automatically create a
ipv6ll address when the interface is raised. However, we currently
drop all foreign addresses before disabling addr_gen_mode.
If the link has been up for a long time, then its kernel-created ipv6ll
address will be correctly dropped. If the link is down, and stays
down until we raise it after finishing configuration, the addr_gen_mode
setting will be disabled when the interface is raised and the kernel
will not create any ipv6ll address.
However, if the interface is raised after dropping foreign config,
but before we have disabled addr_gen_mode, the kernel will create a
ipv6ll tentative address that will eventually finish DAD and become a
working ipv6ll address, even though we have been configured to disable
ipv6ll.
Moving our call to drop foreign addresses to after we have successfully
set addr_gen_mode closes this window; after we disable addr_gen_mode,
we can safely remove foreign ipv6ll addresses (including tentative ones)
and be sure that the kernel will not create any more.
Fixes: #13882.
The kernel will create an ipv6ll tentative address immediately when an
interface is raised if addr_gen_mode is not disabled; and, the kernel does
not notify netlink listeners about any tentative addresses. So it's
possible for an interface to contain tentative ipv6 link-local address(es)
that networkd doesn't know about when all foreign addresses are dropped.
In this case, networkd is later notified about the new ipv6ll address(es)
after they finish DAD and are no longer tentative; but since that's after
networkd has already dropped foreign addresses, they are incorrectly left
on the interface.
Similar to the link->setting_mtu flag, this delays continued configuration
until after the genmode has been successfully set; this is important
because we do not want networkd to raise the interface before the genmode
has been set, as if we're disabling the genmode, raising the interface
before we have successfully disabled the genmode will result in the kernel
creating a ipv6ll address, even though we don't want that.
We should allow the ones that the [Unit] section of regular unit files
may accet, but no other, in particular not the internal deps we
synthesize as reverse of explicitly configured ones, such was WantedBy=.
Fixes: #14251
When in a userns environment we cannot take away per-mount point flags
set on a mount point that was passed to us. Hence we need to be careful
to always check the actual mount flags in place and manipulate only
those flags of them that we actually want to change and not reset more
as side-effect.
We mostly got this right already in
bind_remount_recursive_with_mountinfo(), but didn't in the simpler
bind_remount_one_with_mountinfo(). Catch up.
(The old code assumed that the MountEntry.flags field contained the
right flag settings, but it actually doesn't for new mounts we just
established as for those mount() establishes the initial flags for us,
and we have to read them back to figure out which ones the kernel
picked.)
Fixes: #13622
This cleans up the function in multiple ways:
- change order of parameters to follow our usualy system of putting
return parameters last
- rename return parameter "ret" as we usually do
- don't initialize local variables we override immediately anyway
- downgrade log messages to LOG_DEBUG (since we don't log about any
other errors here above LOG_DEBUG, as this is mostly an "API"-style
function)
- handle that mnt_fs_get_vfs_options() may return NULL (according to
docs)
- manually map the ST_xyz to MS_xyz flags on statvfs(), because while
they are mostly the same, they aren't entirely the same, MS_RELATIME and
ST_RELATIME are defined differently (sad!)
It makes sense to filter state changes for some load states that
shouldn't happen, but the common cases should be accepted, because they
might happen during runtime when "systemctl daemon-reload" is issued and
unit files changed state in between. Otherwise we lose events.
Fixes: #4708
So far we set up a loopback file read-only iff ProtectSystem= and
ProtectHome= both where set to values that mark these dirs read-only.
Let's extend that and also be happy if /home and the root dir are marked
read-only by some other means.
Fixes: #14442
Similar, refuse triggering deps on units that cannot trigger.
And rework how we ignore After= dependencies on device units, to work
the same way.
See: #14142
