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
When probing partitions, we inherit important information from the parent
disk device such as ID_MODEL, and usage of such properties is seen to
be acceptable and well established.
However, we need to exclude filesystem information from the properties
that get inherited. Information about the device content should not be
passed on in this way.
For example, Linux distro install media commonly uses an ISO filesystem
plus a partition table. The ISO filesystem is detected on the main disk
device, but we should not pass down those details to the partitions,
some or all of which may be pointing at storage areas completely distinct
from the ISO filesystem.
This is particularly problematic when adding new partitions on media
set up in this way (since the new partitions are then reported to contain
the parent device's ISO filesystem), or when dealing with more unusual
hybrid ISO layouts. The inaccuracy of information here inversely affects
users of blkid and udev's persistent storage symlinks.
Exclude ID_FS_* properties from the inheritance chain to avoid these
problems.
Fixes: #14408
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
Let's clarify that scope units can fail, but not due to process exit
statusses.
This hopefully clears up some confusion that manifested in #14142: scope
units can fail, but for other reasons than assumed there.
Fixes: #14142
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
Latest meson doesn't work with older python 3.5, which is present on
Ubuntu 16.04. Let's pin in to the latest working version (0.52.1) until
we properly bump all necessary Ubuntu images to 18.04.
See: https://github.com/mesonbuild/meson/issues/6427
The only non-stylistic change is to replace descriptions of how we are
encouraging people to use PrivateTmp= and such, because now they are widely
used.
Build option "link-networkd-shared" to build a statically linked
systemd-networkd by using
-Dlink-udev-shared=false -Dlink-networkd-shared=false
on systems with full systemd stack except systemd-networkd, such
as RHEL/CentOS 8.
To make this easier to understand, let's always log (at debug level)
when we accept or reject each device:
/swapfile: detection of swap file offset on Btrfs is not supported
/swapfile: is a candidate device.
/dev/zram0: ignoring zram swap
/dev/vdb: ignoring device with lower priority
/dev/vdc: ignoring device with lower usable space
...
If we know that hibernation will fail, refuse. This includes cases where
/sys/power/resume is set and doesn't match any device, or
/sys/power/resume_offset is set and we're not on btrfs and it doesn't match.
If /sys/power/resume is not set at all, we still accept the device with the
highest priority (see 6d176522f5 and
88bc86fcf8)
Tested cases:
1. no swap active → refuse
2. just zram swap active → refuse
3. swapfile on btrfs with /sys/power/resume{,_offset} set → OK
4. swapfile on btrfs with /sys/power/resume set, offset not set → refuse
5. swapfile on btrfs with /sys/power/resume set to nonexistent device, offset set → refuse
6. /sys/power/resume not set, offset set, candidate exists → OK (*)
7. /sys/power/resume not set, offset not set, candidate exists → OK
(*) I think this should fail, but I'm leaving that for the next commit.
