This should hopefully help us avoid c&p mistakes. And there are plans to
add more settings like this, which should then be rather straightforward.
There is a slight functional change: the code got uplink handling wrong
and run manager_find_uplink() repeatedly. That part is fixed.
Regardless of whether a mount is setup in initrd or int the main system,
the network default dependencies _netdev should still be honored.
IOW if a mount unit use the following options "x-initrd.mount,_netdev", it
should be ordered against initrd-fs.target, network.target,
network-online.target.
/dev/vdb1 /mnt ext4 x-initrd.mount,_netdev defaults 0 0
Before this patch:
Before=umount.target initrd-fs.target
After=system.slice sysroot.mount dev-vdb1.device -.mount systemd-journald.socket blockdev@dev-vdb1.target
After this patch:
Before=initrd-fs.target umount.target
After=network-online.target -.mount blockdev@dev-vdb1.target dev-vdb1.device sysroot.mount system.slice network.target systemd-journald.socket
First After=local-fs-pre.target wasn't described in the man page although it's
part of the default dependencies automatically set by pid1.
Secondly, Before=local-fs.target was only set if the automount unit was
generated from the fstab-generator because the dep was explicitly
generated. It was also not documented as a default dependency.
Fix it by managing the dep from pid1 instead.
fstab-generator was also handling the default ordering dependencies for mount
units setup in initrd. To do that it was turning the defaults dependencies off
completely and ordered the mount unit against either local-fs.target or
initrd-fs.target or initrd-root-fs.target itself.
But it had the bad side effect to also remove all other default dependencies as
well. Thus if an initrd mount was using _netdev, the network dependencies were
missing.
In general fstab-generator shouldn't use DefaultDependecies=no because it can
handle only a small set of the default dependencies the rest are dealt by pid1.
So this patch makes pid1 handle all default dependencies.
Let's not trigger MACs needlessly.
Ideally everybody would turn on userdb, but if people insist in not
doing so, then let's not attempt to open shadow.
It's a bit ugly to implement this, since shadow information is more than
just passwords (but accound validity metadata), and thus userdb's own
"privieleged" scheme is orthogonal to this, but let's still do this for
the client side.
Fixes: #15105
This patch changes the way user managers set the default umask for the units it
manages.
Indeed one can expect that if user manager's umask is redefined through PAM
(via /etc/login.defs or pam_umask), all its children including the units it
spawns have their umask set to the new value.
Hence make user units inherit their umask value from their parent instead of
the hard coded value 0022 but allow them to override this value via their unit
file.
Note that reexecuting managers with 'systemctl daemon-reexec' after changing
UMask= has no effect. To take effect managers need to be restarted with
'systemct restart' instead. This behavior was already present before this
patch.
Fixes#6077.
When managing a home directory as LUKS image we currently place a
directory at the top that contains the actual home directory (so that
the home directory of the user won't be cluttered by lost-found and
suchlike). On btrfs let's make that a subvol though. This is a good idea
so that possibly later on we can make use of this for automatic history
management.
Fixes: #15121
The commit b3ac5f8cb9 has changed the system mount propagation to
shared by default, and according to the following patch:
https://github.com/opencontainers/runc/pull/208
When starting the container, the pouch daemon will call runc to execute
make-private.
However, if the systemctl daemon-reexec is executed after the container
has been started, the system mount propagation will be changed to share
again by default, and the make-private operation above will have no chance
to execute.
This makes the Environment entries more round-trippable: a similar format is
used for input and output. It is certainly more useful for users, because
showing [unprintable] on anything non-trivial makes systemctl show -p Environment
useless in many cases.
Fixes: #14723 and https://bugzilla.redhat.com/show_bug.cgi?id=1525593.
$ systemctl --user show -p Environment run-*.service
Environment=ASDF=asfd "SPACE= "
Environment=ASDF=asfd "SPACE=\n\n\n"
Environment=ASDF=asfd "TAB=\t\\" "FOO=X X"
non-underlined yellow uses RGB ANSI sequences while the underlined
version uses the paletted ANSI sequences. Let's unify that and use the
RGB sequence for both cases, so that underlined or not doesn't alter the
color.