Docbook styles required those to be present, even though the templates that we
use did not show those names anywhere. But something changed semi-recently (I
would suspect docbook templates, but there was only a minor version bump in
recent years, and the changelog does not suggest anything related), and builds
now work without those entries. Let's drop this dead weight.
Tested with F26-F29, debian unstable.
$ perl -i -0pe 's/\s*<authorgroup>.*<.authorgroup>//gms' man/*xml
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
Old text:
> Note that the User= and
> Group= options are not particularly useful for mount units specifying a
> "Type=" option or using configuration not specified in /etc/fstab;
> mount(8) will refuse options that are not listed in /etc/fstab if it is
> not run as UID 0.
However I recently learnt the following:
> The mount program does not read the /etc/fstab file if both device
> and dir are specified.
Therefore, if both device and dir are specified, the `user` or `users`
options in `fstab` will not have any effect. Run as a normal user,
you will always see
mount: only root can do that
Fix the explanation in the man page.
Also make sure to markup User= and Group= with <varname>.
Systemd services are permitted to be scripts, as well as binary
executables.
The same also applies to the underlying /sbin/mount and /sbin/swapon.
It is not necessary for the user to consider what type of program file
these are. Nor is it necessary with systemd-nspawn, to distinguish between
init as a "binary" v.s. a user-specified "program".
Also fix a couple of grammar nits in the modified sentences.
This has a long history; see see 5261ba9018
which originally introduced the behavior. Unfortunately that commit
doesn't include any rationale, but IIRC the basic issue is that
systemd wants to model the real mount state as units, and symlinks
make canonicalization much more difficult.
At the same time, on a RHEL6 system (upstart), one can make e.g. `/home` a
symlink, and things work as well as they always did; but one doesn't have
access to the sophistication of mount units (dependencies, introspection, etc.)
Supporting symlinks here will hence make it easier for people to do upgrades to
RHEL7 and beyond.
The `/home` as symlink case also appears prominently for OSTree; see
https://ostree.readthedocs.io/en/latest/manual/adapting-existing/
Further work has landed in the nspawn case for this; see e.g.
d944dc9553
A basic limitation with doing this in the fstab generator (and that I hit while
doing some testing) is that we obviously can't chase symlinks into mounts,
since the generator runs early before mounts. Or at least - doing so would
require multiple passes over the fstab data (as well as looking at existing
mount units), and potentially doing multi-phase generation. I'm not sure it's
worth doing that without a real world use case. For now, this will fix at least
the OSTree + `/home` <https://bugzilla.redhat.com/show_bug.cgi?id=1382873> case
mentioned above, and in general anyone who for whatever reason has symlinks in
their `/etc/fstab`.
When "bg" is specified for NFS mounts, and if the server is
not accessible, two behaviors are possible depending on networking
details.
If a definitive error is received, such a EHOSTUNREACH or ECONNREFUSED,
mount.nfs will fork and continue in the background, while /bin/mount
will report success.
If no definitive error is reported but the connection times out
instead, then the mount.nfs timeout will normally be longer than the
systemd.mount timeout, so mount.nfs will be killed by systemd.
In the first case the mount has appeared to succeed even though
it hasn't. This can be confusing. Also the background mount.nfs
will never get cleaned up, even if the mount unit is stopped.
In the second case, mount.nfs is killed early and so the mount will
not complete when the server comes back.
Neither of these are ideal.
This patch modifies the options when an NFS bg mount is detected to
force an "fg" mount, but retain the default "retry" time of 10000
minutes that applies to "bg" mounts.
It also imposes "nofail" behaviour and sets the TimeoutSec for the
mount to "infinity" so the retry= time is allowed to complete.
This provides near-identical behaviour to an NFS bg mount started directly
by "mount -a". The only difference is that systemd will not wait for
the first mount attempt, while "mount -a" will.
Fixes#6046
Currently fstab entries with 'nofail' option are mounted
asynchronously and there is no way how to specify dependencies
between such fstab entry and another units. It means that
users are forced to write additional dependency units manually.
The patch introduces new systemd fstab options:
x-systemd.before=<PATH>
x-systemd.after=<PATH>
- to specify another mount dependency (PATH is translated to unit name)
x-systemd.before=<UNIT>
x-systemd.after=<UNIT>
- to specify arbitrary UNIT dependency
For example mount where A should be mounted before local-fs.target unit:
/dev/sdb1 /mnt/test/A none nofail,x-systemd.before=local-fs.target
Since commit 9d06297, mount units from mountinfo are not bound to their devices
anymore (they use the "Requires" dependency instead).
This has the following drawback: if a media is mounted and the eject button is
pressed then the media is unconditionally ejected leaving some inconsistent
states.
Since udev is the component that is reacting (no matter if the device is used
or not) to the eject button, users expect that udev at least try to unmount the
media properly.
This patch introduces a new property "SYSTEMD_MOUNT_DEVICE_BOUND". When set on
a block device, all units that requires this device will see their "Requires"
dependency upgraded to a "BindTo" one. This is currently only used by cdrom
devices.
This patch also gives the possibility to the user to restore the previous
behavior that is bind a mount unit to a device. This is achieved by passing the
"x-systemd.device-bound" option to mount(8). Please note that currently this is
not working because libmount treats the x-* options has comments therefore
they're not available in utab for later application retrievals.
This adds a new systemd fstab option x-systemd.mount-timeout. The option
adds a timeout value that specifies how long systemd waits for the mount
command to finish. It allows to mount huge btrfs volumes without issues.
This is equivalent to adding option TimeoutSec= to [Mount] section in a
mount unit file.
fixes#4055
Apparently, util-linux' mount command implicitly drops the smack-related
options anyway before passing them to the kernel, if the kernel doesn't
know SMACK, hence there's no point in duplicating this in systemd.
Fixes#1696
For all units ensure there's an "Automatic Dependencies" section in the
man page, and explain which dependencies are automatically added in all
cases, and which ones are added on top if DefaultDependencies=yes is
set.
This is also done for systemd.exec(5), systemd.resource-control(5) and
systemd.unit(5) as these pages describe common behaviour of various unit
types.
This option specifies the label to assign the root of the file system if
it lacks the Smack extended attribute. Note that this option will be
ignored if kernel does not support the Smack feature by runtime
checking.
This did not really work out as we had hoped. Trying to do this upstream
introduced several problems that probably makes it better suited as a
downstream patch after all. At any rate, it is not releaseable in the
current state, so we at least need to revert this before the release.
* by adjusting the path to binaries, but not do the same thing to the
search path we end up with inconsistent man-pages. Adjusting the search
path too would be quite messy, and it is not at all obvious that this is
worth the effort, but at any rate it would have to be done before we
could ship this.
* this means that distributed man-pages does not make sense as they depend
on config options, and for better or worse we are still distributing
man pages, so that is something that definitely needs sorting out before
we could ship with this patch.
* we have long held that split-usr is only minimally supported in order
to boot, and something we hope will eventually go away. So before we start
adding even more magic/effort in order to make this work nicely, we should
probably question if it makes sense at all.
In particular, use /lib/systemd instead of /usr/lib/systemd in distributions
like Debian which still have not adopted a /usr merge setup.
Use XML entities from man/custom-entities.ent to replace configured paths while
doing XSLT processing of the original XML files. There was precedent of some
files (such as systemd.generator.xml) which were already using this approach.
This addresses most of the (manual) fixes from this patch:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/Fix-paths-in-man-pages.patch?h=experimental-220
The idea of using generic XML entities was presented here:
http://lists.freedesktop.org/archives/systemd-devel/2015-May/032240.html
This patch solves almost all the issues, with the exception of:
- Path to /bin/mount and /bin/umount.
- Generic statements about preference of /lib over /etc.
These will be handled separately by follow up patches.
Tested:
- With default configure settings, ran "make install" to two separate
directories and compared the output to confirm they matched exactly.
- Used a set of configure flags including $CONFFLAGS from Debian:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules
Installed the tree and confirmed the paths use /lib/systemd instead of
/usr/lib/systemd and that no other unexpected differences exist.
- Confirmed that `make distcheck` still passes.
Currently we have no way how to specify dependencies between fstab
entries (or another units) in the /etc/fstab. It means that users are
forced to bypass fstab and write .mount units manually.
The patch introduces new systemd fstab options:
x-systemd.requires=<PATH>
- to specify dependence an another mount (PATH is translated to unit name)
x-systemd.requires=<UNIT>
- to specify dependence on arbitrary UNIT
x-systemd.requires-mounts-for=<PATH ...>
- to specify dependence on another paths, implemented by
RequiresMountsFor=. The option may be specified more than once.
For example two bind mounts where B depends on A:
/mnt/test/A /mnt/test/A none bind,defaults
/mnt/test/A /mnt/test/B none bind,x-systemd.requires=/mnt/test/A
More complex example with overlay FS where one mount point depends on
"low" and "upper" directories:
/dev/sdc1 /mnt/low ext4 defaults
/dev/sdc2 /mnt/high ext4 defaults
overlay /mnt/merged overlay lowerdir=/mnt/low,upperdir=/mnt/high/data,workdir=/mnt/high/work,x-systemd.requires-mounts-for=/mnt/low,x-systemd.requires-mounts-for=mnt/high
https://bugzilla.redhat.com/show_bug.cgi?id=812826https://bugzilla.redhat.com/show_bug.cgi?id=1164334
systemd stops adding automatic dependencies on swap.target to swap
units. If a dependency is required, it has to be added by unit
configuration. fstab-generator did that already, except that now it is
modified to create a Requires or Wants type dependency, depending on
whether nofail is specified in /etc/fstab. This makes .swap units
obey the nofail/noauto options more or less the same as .mount units.
Documentation is extended to clarify that, and to make
systemd.mount(5) and system.swap(5) more similar. The gist is not
changed, because current behaviour actually matches existing
documentation.
https://bugs.freedesktop.org/show_bug.cgi?id=86488
It is annoying when we have dead links on fd.o.
Add project='man-pages|die-net|archlinux' to <citerefentry>-ies.
In generated html, add external links to
http://man7.org/linux/man-pages/man, http://linux.die.net/man/,
https://www.archlinux.org/.
By default, pages in sections 2 and 4 go to man7, since Michael
Kerrisk is the autorative source on kernel related stuff.
The rest of links goes to linux.die.net, because they have the
manpages.
Except for the pacman stuff, since it seems to be only available from
archlinux.org.
Poor gummiboot gets no link, because gummitboot(8) ain't to be found
on the net. According to common wisdom, that would mean that it does
not exist. But I have seen Kay using it, so I know it does, and
deserves to be found. Can somebody be nice and put it up somewhere?
Lennart Poettering