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.
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
Failing after a single check leads to extra sleeps scattered through
test cases, and can also lead to false failures. Instead perform a
recheck for a number of seconds until the state matches, and fail only
if the timeout is exceeded.
This allows removing all the manual sleeps in the testcases.
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.
There are sometimes users who put unit files in a location that is inaccessible
when systemd starts although they are not found and thus not started because
the corresponding mount units have not activated yet.
There is already a warning for such issue in man 8 systemctl:
link PATH...
...<snip>...
The file system where
the linked unit files are located must be accessible
when systemd is started (e.g. anything underneath /home
or /var is not allowed, unless those directories are
located on the root file system).
However, it looks that it's difficult to find the warning because introductory
users typically doesn't know systemctl link.
Although there is a description in UNIT FILE LOAD PATH pointing to systemctl
link, symlink is now not explicitly mentioned there and thus users doesn't
easily get aware of they should read it.
To deal with this, let's describe "symlink" and "systemctl link" more
explicitly in UNIT FILE LOAD PATH.
The document is rather huge, and a specific link is easier to consume. The form
is a bit strange because troff puts the symlink at the bottom, keyed by title,
so we need to use the same link target in all places.
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!)
Zbigniew Jędrzejewski-Szmek