This refactors the Unit structure a bit: all cgroup-related state fields
are moved to a new structure CGroupRuntime, which is only allocated as
we realize a cgroup.
This is both a nice cleanup and should make unit structures considerably
smaller that have no cgroup associated, because never realized or
because they belong to a unit type that doesn#t have cgroups anyway.
This makes things nicely symmetric:
ExecContext → static user configuration about execution
ExecRuntime → dynamic user state of execution
CGroupContext → static user configuration about cgroups
CGroupRuntime → dynamic user state of cgroups
And each time the XyzContext is part of the unit type structures such as
Service or Slice that need it, but the runtime object is only allocated
when a unit is started.
We already have specifiers that resolve to $XDG_STATE_HOME, and
$XDG_CONFIG_HOME. $XDG_DATA_HOME is in a similar vein.
It allows units belonging to the user service manager to correctly look
into ~/.local/share. I imagine this would be most useful inside of
condition checks (i.e. only run a service on session startup if some
data is not found in ~/.local/share) or in the inotify monitoring of a
.path unit
This adds support for the new XDG_STATE_HOME env var that was added to
the xdg basedir spec. Previously, because the basedir spec didn't know
the concept we'd alias the backing dir for StateDirectory= to the one
for ConfigurationDirectory= when runnin in --user mode. With this change
we'll make separate. This brings us various benefits, such as proper
"systemctl clean" support, where we can clear service state separately
from service configuration, now in user mode too.
This does not come without complications: retaining compatibility with
older setups is difficult, because we cannot possibly identitfy which
files in existing populated config dirs are actually "state" and which
one are true" configuration.
Hence let's deal with this pragmatically: if we detect that a service
that has both dirs configured only has the configuration dir existing,
then symlink the state dir to the configuration dir to retain
compatibility.
This is not great, but it's the only somewhat reasonable way out I can
see.
Fixes: #25739
Let's clean up validation/escaping of cgroup names. i.e. split out code
that tests if name needs escaping. Return proper error codes, and extend
test a bit.
In various tools and services we have a per-system and per-user concept.
So far we sometimes used a boolean indicating whether we are in system
mode, or a reversed boolean indicating whether we are in user mode, or
the LookupScope enum used by the lookup path logic.
Let's address that, in introduce a common enum for this, we can use all
across the board.
This is mostly just search/replace, no actual code changes.
We would resolve those specifiers to the calling user/group. This is mostly OK
when done in the manager, because the manager generally operates as root
in system mode, and a non-root in user mode. It would still be wrong if
called with --test though. But in systemctl, this would be generally wrong,
since we can call 'systemctl --system' as a normal user, either for testing
or even for actual operation with '--root=…'.
When operating in --global mode, %u/%U/%g/%G should return an error.
The information whether we're operating in system mode, user mode, or global
mode is passed as the data pointer to specifier_group_name(), specifier_user_name(),
specifier_group_id(), specifier_user_id(). We can't use userdata, because
it's already used for other things.
Fixes#6308: people want to be able to link a unit file via 'systemctl enable'
from a git checkout or such and refer to other files in the same repo.
The new specifiers make that easy.
%y/%Y is used because other more obvious choices like %d/%D or %p/%P are
not available because at least on of the two letters is already used.
The new specifiers are only available in units. Technically it would be
trivial to add then in [Install] too, but I don't see how they could be
useful, so I didn't do that.
I added both %y and %Y because both were requested in the issue, and because I
think both could be useful, depending on the case. %Y to refer to other files
in the same repo, and %y in the case where a single repo has multiple unit files,
and e.g. each unit has some corresponding asset named after the unit file.
This fixes repart's, systemctl's, sysusers' and tmpfiles' specifier
expansion to honour the root dir specified with --root=. This is
relevant for specifiers such as %m, %o, … which are directly sourced
from files on disk.
This doesn't try to be overly smart: specifiers referring to runtime
concepts (i.e. boot ID, architecture, hostname) rather than files on the
medium are left as is. There's certainly a point to be made that they
should fail in case --root= is specified, but I am not entirely convinced
about that, and it's certainly something we can look into later if
there's reason to.
I wondered for a while how to hook this up best, but given that quite a
large number of specifiers resolve to data from files on disks, and most
of our tools needs this, I ultimately decided to make the root dir a
first class parameter to specifier_printf().
Replaces: #16187Fixes: #16183
In a later commit we intend to move the slice logic to use proper
dependencies instead of a "UnitRef" object. This preparatory commit
drops direct use of the slice UnitRef object for a static inline
function UNIT_GET_SLICE() that is both easier to grok, and allows us to
easily replace its internal implementation later on.
We usually call specifier_printf() and then check the validity of
the result. In many cases, validity checkers, e.g. path_is_valid(),
refuse too long strings. This makes specifier_printf() refuse such
long results earlier.
Moreover, unit_full_string() and description field in sysuser now
refuse results longer than LONG_LINE_MAX. config_parse() already
refuses the line longer than LONG_LINE_MAX. Hence, it should be ok
to set the same value as the maximum length of the resolved string.
In many cases the tables are largely the same, hence define a common set
of macros to generate the common parts.
This adds in a couple of missing specifiers here and there, so is more
thant just refactoring: it actually fixes accidental omissions.
Note that some entries that look like they could be unified under these
macros can't really be unified, since they are slightly different. For
example in the DNSSD service logic we want to use the DNSSD hostname for
%H rather than the unmodified kernel one.
As described in #15603, it is a fairly common setup to use a fqdn as the
configured hostname. But it is often convenient to use just the actual
hostname, i.e. until the first dot. This adds support in tmpfiles, sysusers,
and unit files for %l which expands to that.
Fixes#15603.
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
Commit 250e9fadbc introduced
support for %j/%J specifier in unit files. The function
unit_name_printf is used in unit dependency resolution,
such as Wants / After directives, but was missing support
for the %j. Add to allow directives such as:
[Unit]
Wants=bar-%j.target
Fixes: systemd/systemd#11217
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
It would be very wrong if any of the specfier printf calls modified
any of the objects or data being printed. Let's mark all arguments as const
(primarily to make it easier for the reader to see where modifications cannot
occur).
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.
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).
Those are quite similar to %i/%I, but refer to the last dash-separated
component of the name prefix.
The new functionality of dash-dropins could largely supersede the template
functionality, so it would be tempting to overload %i/%I. But that would
not be backwards compatible. So let's add the two new letters instead.
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.
The code in install-printf.c and unit-printf.c for these is pretty much
the same and very generic. Let's move this all over to the generic
specifier.c, and share the implementations.
This augments %t which already resolves to the runtime directory root, and
should be useful for units that want to pass any of these paths in
command line arguments.
Example:
ExecStart=/usr/bin/mydaemon --datadir=%S/mydaemon
Why not expose a specifier resolving directly to the configured
state/runtime/cache/log dir? Three reasons:
1. Specifiers should be independent of configuration of the unit itself,
and StateDirectory= and friends are unit configuration. See
03fc9c723c and related work.
2. We permit multiple StateDirectory= values per unit, and it hence
wouldn't be clear which one is passed.
3. We already have %t for the runtime directory root, and we should
continue with the same scheme.
This introduces {State,Cache,Log,Configuration}Directory= those are
similar to RuntimeDirectory=. They create the directories under
/var/lib, /var/cache/, /var/log, or /etc, respectively, with the mode
specified in {State,Cache,Log,Configuration}DirectoryMode=.
This also fixes#6391.
%c and %r rely on settings made in the unit files themselves and hence resolve
to different values depending on whether they are used before or after Slice=.
Let's simply deprecate them and drop them from the documentation, as that's not
really possible to fix. Moreover they are actually redundant, as the same
information may always be queried from /proc/self/cgroup and /proc/1/cgroup.
(Accurately speaking, %R is actually not broken like this as it is constant.
However, let's remove all cgroup-related specifiers at once, as it is also
redundant, and doesn't really make much sense alone.)
unit_name_printf() is usually what we use when the resulting string shall
qualify as unit name, and it hence avoids resolving specifiers that almost
certainly won't result in valid unit names.
Add a couple of more specifiers that unit_full_printf() resolves also to the
list unit_name_printf() resolves, as they are likely to be useful in valid unit
names too. (Note that there might be cases where this doesn't hold, but we
should still permit this, as more often than not they are safe, and if people
want to use them that way, they should be able to.)
We don't have plural in the name of any other -util files and this
inconsistency trips me up every time I try to type this file name
from memory. "formats-util" is even hard to pronounce.
Previously, we had two enums ManagerRunningAs and UnitFileScope, that were
mostly identical and converted from one to the other all the time. The latter
had one more value UNIT_FILE_GLOBAL however.
Let's simplify things, and remove ManagerRunningAs and replace it by
UnitFileScope everywhere, thus making the translation unnecessary. Introduce
two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking
if we are running in one or the user context.
Previously, the %u, %U, %s and %h specifiers would resolve to the user
name, numeric user ID, shell and home directory of the user configured
in the User= setting of a unit file, or the user of the manager instance
if no User= setting was configured. That at least was the theory. In
real-life this was not ever actually useful:
- For the systemd --user instance it made no sense to ever set User=,
since the instance runs in user context after all, and hence the
privileges to change user IDs don't even exist. The four specifiers
were actually not useful at all in this case.
- For the systemd --system instance we did not allow any resolving that
would require NSS. Hence, %s and %h were not supported, unless
User=root was set, in which case they would be hardcoded to /bin/sh
and /root, to avoid NSS. Then, %u would actually resolve to whatever
was set with User=, but %U would only resolve to the numeric UID of
that setting if the User= was specified in numeric form, or happened
to be root (in which case 0 was hardcoded as mapping). Two of the
specifiers are entirely useless in this case, one is realistically
also useless, and one is pretty pointless.
- Resolving of these settings would only happen if User= was actually
set *before* the specifiers where resolved. This behaviour was
undocumented and is really ugly, as specifiers should actually be
considered something that applies to the whole file equally,
independently of order...
With this change, %u, %U, %s and %h are drastically simplified: they now
always refer to the user that is running the service instance, and the
user configured in the unit file is irrelevant. For the system instance
of systemd this means they always resolve to "root", "0", "/bin/sh" and
"/root", thus avoiding NSS. For the user instance, to the data for the
specific user.
The new behaviour is identical to the old behaviour in all --user cases
and for all units that have no User= set (or set to "0" or "root").
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Adrian Vovk
Frantisek Sumsal
Yu Watanabe
Patrick Williams
Davide Cavalca
Daniel Mack
Tom Gundersen
Evgeny Vereshchagin