IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
