When wrong element types are used, directives are sometimes placed in the wrong
section. Also, strip part of text starting with "'", which is used in a few
places and which is displayed improperly in the index.
The synopsis section would describe config file paths, but not their
syntax. Let's add a short table that so that it's possible to quickly
remind oneself what the different letter mean.
The "include" files had type "book" for some raeason. I don't think this
is meaningful. Let's just use the same everywhere.
$ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
We would describe tmpfiles.d through what systemd-tmpfiles does with them, but
I think it's better to start with a geneneral statement what they are. Also,
let's make the description of volatile file systems less prominent.
Also, strenghten the advice to use RuntimeDirectory and mention
{Cache,Logs,Configuration,State}Directory=.
I think it is OK if some option is described as "similar to ..., but in
addition ...", as long as the "in addition" part is strictly additive this is
unambiguous. Otherwise, we'd have to repeat a lot of text, and then we'd
probably forget to adjust some of the descriptions when doing changes.
But when the "in addition" part is about replacing or removing parts of
functionality, it is better to avoid this pattern and describe the later option
from scratch.
Some paragraph breaks are added and minor changes made. UID/GID is changed to
user/group, since we generally expect user/group names to be used, not numeric
ids.
Fixes#11115.
It's obsolete, stop mentioning it. Let's not confuse people suggests it
would be OK to use that, because it really isn't anymore, and it gives
us trouble with merging idenctical lines.
This is an implementation that covers making errors encountered when writing
file content optionally fatal. If this is something that folks would want I'll
add handling of this for all the other directives. I'd appreciate suggestions
on how this might better be structured as well (use of a goto fail or such) as
I'm not super happy with the approach.
The qgroup logic (types 'q' and 'Q') only has an effect if there's no previous
setup at all, and any explicitly configured subvolumes with their qgroups are
left entirely unmodified.
The idea is that if users want a different logic than the one we set up by
default, then by all means they should do that before hand, and tmpfiles won't
override their logic.
One mention of --user was missing the surrounding <option> tag, making
the table look inconsistent (though the inconsistency is less obvious
after the reordering in 709f4c472c, since the four specifiers mentioning
the --user option are no longer immediately adjacent).
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
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.
This corresponds nicely with the specifiers we already pass for
/var/lib, /var/cache, /run and so on.
This is particular useful to update the test-path service files to
operate without guessable files, thus allowing multiple parallel
test-path invocations to pass without issues (the idea is to set $TMPDIR
early on in the test to some private directory, and then only use the
new %T or %V specifier to refer to it).
Usually, we order our settings in our unit files in a logical order,
grouping related settings together, and putting more relevant stuff
first, instead of following a strictly alphabetical order.
For specifiers I think it makes sense to follow an alphabetical order
however, since they literally are just characters, and hence I think the
concept of alphabetical ordering is much more commanding for them. Also,
since specifiers are usually not used in combination, but mostly used
indepdently of each other I think it's not that important to group
similar ones together.
No other changes except the reordering.
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.
This documents how the age of a file is determined, which previously was
only alluded to in other parts of the documentation. Fixes#8091.
The phrasings of “last modification timestamp” etc. are taken from
man:inode(7) (as of man-pages 4.14). The debug messages in tmpfiles.c
use different messages (“modify time”), which according to a code
comment follow man:stat(1); however, my copy of that manpage (from GNU
coreutils 8.29) documents %y as “time of last data modification”
instead.
CHANGE OF BEHAVIOUR — with this commit "f" line's behaviour is altered
to match what the documentation says: if an "argument" string is
specified it is written to the file only when the file didn't exist
before. Previously, it would be appended to the file each time
systemd-tmpfiles was invoked — which is not a particularly useful
behaviour as the tool is not idempotent then and the indicated files
grow without bounds each time the tool is invoked.
I did some spelunking whether this change in behaviour would break
things, but afaics nothing relies on the previous O_APPEND behaviour of
this line type, hence I think it's relatively safe to make "f" lines
work the way the docs say, rather than adding a new modifier for it or
so.
Triggered by:
https://lists.freedesktop.org/archives/systemd-devel/2018-January/040171.html
Currently, we create leading directories implicitly for all lines that
create directory or directory-like nodes.
With this, we also do the same for a number of other lines: f/F, C, p,
L, c/b (that is regular files, pipes, symlinks, device nodes as well as
file trees we copy).
The leading directories are created with te default access mode of 0755.
If something else is desired, users should simply declare appropriate
"d" lines.
Fixes: #7853
sd_path_home() returns ENXIO when a variable (such as $XDG_RUNTIME_DIR) is not
defined. Previously we used ENOKEY for unresolvable specifiers. To avoid having
two codes, or translating ENXIO to ENOKEY, I replaced ENOKEY use with ENXIO.
v2:
- use sd_path_home and change to ENXIO everywhere
This commit adds specifiers %U, %u and %h for the user UID, name and
home directory, respectively.
[zj: drop untrue copy-pasted comments and move the next text
to the new "Specifiers" section.
Now that #7444 has been merged, also drop the specifier functions.]
The code intentionally ignored unknown specifiers, treating them as text. This
needs to change because otherwise we can never add a new specifier in a backwards
compatible way. So just treat an unknown (potential) specifier as an error.
In principle this is a break of backwards compatibility, but the previous
behaviour was pretty much useless, since the expanded value could change every
time we add new specifiers, which we do all the time.
As a compromise for backwards compatibility, only fail on alphanumerical
characters. This should cover the most cases where an unescaped percent
character is used, like size=5% and such, which behave the same as before with
this patch. OTOH, this means that we will not be able to use non-alphanumerical
specifiers without breaking backwards compatibility again. I think that's an
acceptable compromise.
v2:
- add NEWS entry
v3:
- only fail on alphanumerical
Fixes#6639.
(This behaviour of systemd-sysusers is long established, so it's better
to adjust the documentation rather than change the code. If there are any
situations out there where it matters, users must have adjusted to the
current behaviour.)
Currently if tmpfiles is run with force on symlink creation but there already
exists a directory at that location, the creation will fail. This change
updates the behavior to remove the directory with rm_fr and then attempts to
create the symlink again.
I wanted to add a config line that would empty a directory
without creating it if doesn't exist. Existing actions don't allow
this.
v2: properly add 'e' to needs_glob() and takes_ownership()
- do not suggest that vendor configuration files should be in
/etc, use /usr/lib/tmpfiles.d instead
- split the first example, because the text talked about "needing
two directories", but then a smack attribute was also set, and
on a different path, which looked like a typo. Replace that
with the example from original patch [1] which added 't'.
- fix the example for /var/tmp/abrt. The 'x' line was redundant,
because /var/tmp/abrt/* is already filtered because "d /var/tmp/abrt"
overrides "d /var/tmp".
[1] http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/25051
It's not a good idea to create subvolumes for parts of the OS tree (such
as /home, or /var) if the root directory is not a subvolume too. We
shouldn't assume control of "heavier" objects such as subvolumes, if the
originating object (the root directory) is a "light-weight" object, i.e.
a plain directory.
Effectively this means that chroot() environments that are run on a
plain directory do not have to deal with problems around systemd
creating subvolumes that cannot be removed with a simple "rm" anymore.
However, if the chroot manager creates a proper subvolume for such an
environment it will also get further subvolumes placed in there, under
the assumption that the manager understands the concept of subvolumes in
that case.
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.
Generally, we will not follow symlinks, except for "w".
Avoid documentation for now for fifo, device node, directory lines,
which currently follow symlinks but better shouldn't.
For ACLs to be valid, a set of entries for user, group, and other
must be always present. Always add those entries.
While at it, only add the mask ACL if it is actually required, i.e.
when at least on ACL for non-owner group or user exists.
For types which adapt existing files it is generally more useful to accept
globs.
In analogy to z and Z, add recursive versions using uppercase letters.
Technically, making a accept globs is backwards incompatible, but in
practice it probably isn't yet widely used and we can assume that most
people don't create files with wildcards in names.
Functions which are used as callbacks, but not directly on items, are
renamed not to have "item_" prefix.
The data structure used by tmpfiles is changed: instead of hashmaps
mapping {path → Item*} we now have hashmaps containing
{path -> ItemArray}, where ItemArray contains a pointer
to an array of Items.
For current code it doesn't matter much, but when we add new types it
is easier to simply add a new Item for a given path, then to coalesce
multiple lines into one Item.
In the future, this change will also make it possible to remember the
file and line where each Item originates, and use that in reporting
errors. Currently this is not possible, since each Item can be created
from multiple lines.
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:
name=value
All other fields are ignored.
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
Previously it would recursively copy the entire tree in, and descend
into subdirectories even if the destination already exists. Let's do
what the documentation says and not do that.
If files down the tree shall be copied too, they should get their own
"C" lines.
If two lines refer to paths that are suffix and prefix of each other,
then always process the prefix first, the suffix second. In all other
cases strictly process rules in the order they appear in the files.
This makes creating /var/run as symlink to /run a lot more fun, since it
is automatically created first.
"m" so far has been a non-globbing version of "z". Since this makes it
quite redundant, let's get rid of it. Remove "m" from the man pages,
beef up "z" docs instead, and make "m" nothing more than a compatibility
alias for "z".
