Clean up the naming of the sd-path enums. Previously, the more recently
added fields where named in the form SD_PATH_xyz_DIR and
SD_PATH_xyz_PATH, while the older fields where called just SD_PATH_xyz
and SD_PATH_SEARCH_xyz. Let's clean this up, to come to a more unified
way how we name this stuff.
I opted to stick to the old naming, i.e. dropthe suffixes. It's a bit of
a bike-shedding question of course, but I think there's a good reason to
avoid the additional DIR and PATH suffixes: the enum prefix contains
"PATH" anyway (i.e. "SD_PATH_"), so including PATH twice in each name is
redundant. Moreover, the key difference between the enums with the "dir"
and the "path" in the name is that the latter are *seach* paths, and I
think this is better emphasized by sticking to the "SEARCH" in the name.
Moreover dropping the suffixes makes the identifiers a lot shorter, in
particular in the "systemd-path" list output. And that's always good.
This means the naming pkgconfig file and in sd-path slightly deviate
(though the mapping is very simple), but I think that's OK, given that
this is developer facing and not user facing.
This generator can be used by desktop environments to launch autostart
applications and services. The feature is an opt-in, triggered by
xdg-desktop-autostart.target being activated.
Also included is the new binary xdg-autostart-condition. This binary is
used as an ExecCondition to test the OnlyShowIn and NotShowIn XDG
desktop file keys. These need to be evaluated against the
XDG_CURRENT_DESKTOP environment variable which may not be known at
generation time.
Co-authored-by: Henri Chain <henri.chain@enioka.com>
It doesn't make much sense to have ConfigureWithoutCarrier set, but not
IgnoreCarrierLoss; all the configuration added during initial interface
bring-up will be lost at the first carrier up/down.
This allows users to configure a subnet id that should be used instead
of automatically (sequentially) assigned subnets. The previous attempt
had the downside that the subnet id would not be the same between
networkd restarts. In some setups it is desirable to have predictable
subnet ids across restarts of services and systems.
The code for the assignment had to be broken up into two pieces. One of
them is the old (sequential) assignment of prefixes and the other is the
new assignment based on configured subnet ids. The new assignment code
has to be executed first and has to be taken into account when (later
on) allocating the "old" subnets from the same pool.
Instead of having one iteration through the links we are now trying to
allocate a prefix for every link on every delegated prefix, unless they
received an assignment in a previous iteration.
Defines how link-local and autoconf addresses are generated.
0: generate address based on EUI64 (default)
1: do no generate a link-local address, use EUI64 for addresses generated
from autoconf
2: generate stable privacy addresses, using the secret from
stable_secret (RFC7217)
3: generate stable privacy addresses, using a random secret if unset
This variable is read by the module and can be used instead of the
suspend= PAM module parameter.
It is also set for the session itself to make debugging easy.
Much like systemd.condition-needs-update= this new switch allows
overriding of a unit file condition, but this time its
ConditionFirstBoot=.
Usecase is also primarily debugging, but could be useful for other
schemes too.
The systemd pstore service archives the contents of /sys/fs/pstore
upon boot so that there is room for a subsequent dump. The issue is
that while the service is present, the kernel still needs to be
configured to write data into the pstore. The kernel has two
parameters, crash_kexec_post_notifiers and printk.always_kmsg_dump,
that control writes into pstore.
The crash_kexec_post_notifiers parameter enables the kernel to write
dmesg (including stack trace) into pstore upon a panic, and
printk.always_kmsg_dump parameter enables the kernel to write dmesg
upon a shutdown (shutdown, reboot, halt).
As it stands today, these parameters are not managed/manipulated by
the systemd pstore service, and are solely reliant upon the user [to
have the foresight] to set them on the kernel command line at boot, or
post boot via sysfs. Furthermore, the user would need to set these
parameters in a persistent fashion so that that they are enabled on
subsequent reboots.
This patch introduces the setting of these two kernel parameters via
the systemd tmpfiles technique.
Link groups are similar to port ranges found in managed switches.
You can add network interfaces to a numbered group and perform operations
on all the interfaces from that group at once.
These arguments contain UserRecord structures serialized to JSON,
however only the "secret" part of it, not a whole user record. We do
this since the secret part is conceptually part of the user record and
in some contexts we need a user record in full with both secret and
non-secret part, and in others just the secret and in other just the
non-secret part, but we want to keep this in memory in the same logic.
Hence, let's rename the arguments where we expect a user record
consisting only of the secret part to "secret".
Fixes: #15757
(Note there's quite some confusion regarding "exit status" vs. "exit
code" in the docs here. We should clean this up fully one day. This
change tries to fix some occasions of the wrong use, but not all.)
I was looking for the explanation for the exclamation mark in the text,
and couldn't find it, searching for "!". Let's make this easier, and
indicate the character meant.
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.
I wasn't 100% convinced that this is the right thing to do, hence the separate
commit. But e.g. for paths we index all mentions, so I think it's reasonable to
do the same here.
The hack with getparent().txt is not very pretty, but the whole
thing seems to work well enough. It is useful to figure out whihc
specifiers are supported where.
In the beginning, it was rather short, and reasonable to include inline.
Now it is long and unwieldy, let's split it out.
While at it, let's reindent and wrap using our current standards.
The name of the helper didn't match the name of the meson target, which was
always confusing me. With this change, we consistenly use "update" to
re-generate things which we otherwise keep in vc, and "make" for things
which are generated during each build.
This adds the --exit-idle-time argument that causes
systemd-socket-proxyd to exit when there has been an idle period. An
open connection prevents the idle period from starting, even if there is
no activity on that connection.
When combined with another service that uses StopWhenUnneeded=, the
proxy exiting can trigger a resource-intensive process to exit. So
although the proxy may consume minimal resources, significant resources
can be saved indirectly.
Fixes#2106
I'm not sure if the LogTarget property is sufficiently general to be made into
a property that can be generally implemented. It is very closely tied to the internal
systemd logic. The other two seem fine thoough.
This has the advantage that the executables are always in place and we don't
need any units to exist on the bus, so we can eventually hook this up into
a normal build system. (Probably as a build time check.)
For units which are aliases of other units, reporting preset status as
"enabled" is rather misleading. For example, dbus.service is an alias of
dbus-broker.service. In list-unit-files we'd show both as "enabled". In
particular, systemctl preset ignores aliases, so showing any preset status at
all is always going to be misleading. Let's introduce a new state "alias" and
use that for all aliases.
I was trying to avoid adding a new state, to keep compatibility with previous
behaviour, but for alias unit files it simply doesn't seem very useful to show
any of the existing states. It seems that the clearly showing that those are
aliases for other units will be easiest to understand for users.
5238d9a83a renames this to exit-status, but systemd.service was not
updated.
The rest of the doc seems a bit inconsistent in its use of the terms
"exit code" and "exit status", but it's not that confusing, so leave
those alone for now.
We probably can migrate even more, but for now let's just migrate those
which have the 1:1 identical text everywhere.
(Also, let's add the % entry to all specifier tables)
Add note for change of behaviour in systemd-notify, where parent pid trick
is only used when --no-block is passed, and with enough privileges ofcourse.
Also, fix a small error in systemd(1).
This adds the sd_notify_barrier function, to allow users to synchronize against
the reception of sd_notify(3) status messages. It acts as a synchronization
point, and a successful return gurantees that all previous messages have been
consumed by the manager. This can be used to eliminate race conditions where
the sending process exits too early for systemd to associate its PID to a
cgroup and attribute the status message to a unit correctly.
systemd-notify now uses this function for proper notification delivery and be
useful for NotifyAccess=all units again in user mode, or in cases where it
doesn't have a control process as parent.
Fixes: #2739
A service can specify FDSTORE=1 FDPOLL=0 to request that PID1 does not
poll the fd to remove them on error. If set, fds will only be removed on
FDSTOREREMOVE=1 or when the service is done.
Fixes: #12086
With cgroup v2 the cgroup freezer is implemented as a cgroup
attribute called cgroup.freeze. cgroup can be frozen by writing "1"
to the file and kernel will send us a notification through
"cgroup.events" after the operation is finished and processes in the
cgroup entered quiescent state, i.e. they are not scheduled to
run. Writing "0" to the attribute file does the inverse and process
execution is resumed.
This commit exposes above low-level functionality through systemd's DBus
API. Each unit type must provide specialized implementation for these
methods, otherwise, we return an error. So far only service, scope, and
slice unit types provide the support. It is possible to check if a
given unit has the support using CanFreeze() DBus property.
Note that DBus API has a synchronous behavior and we dispatch the reply
to freeze/thaw requests only after the kernel has notified us that
requested operation was completed.
It turns out that our man page didn't describe the handling of single-label
names almost at all. This probably adds to the confusion regarding the subject.
So let's first describe what our current implementation is doing.
Quoting https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/:
> Applications and platforms that apply a suffix search list to a single-label
> name are in conformance with IETF standards track RFCs. Furthermore,
> applications and platforms that do not query DNS for a TLD are in conformance
> with IETF standards track recommendations
Current behaviour is in line with that recommendation.
For #13763.
Anyone previously using the UseRoutes=false parameter expected their
dhcp4-provided gateway route to be ignored, as well. However, with
the introduction of the UseGateway= parameter, this is no longer true.
In order to keep backwards compatibility, this sets the UseGateway=
default value to whatever UseRoutes= has been set to.
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.
We use udev to wait for /dev/loopX devices to be fully proped hence we
need an implicit ordering dependency on it, for RootImage= to work
reliably in early boot, too.
Fixes: #14972
Follow-up for f92c8d1c67.
directives.index:
- This index contains 3398 entries in 19 sections, referring to 333 individual
+ This index contains 4316 entries in 19 sections, referring to 333 individual
This is useful to raise the log level for a single transaction or a few,
without affecting other state of the resolved as a restart would.
The log level can only be set, I didn't bother with having the ability
to restore the original as in pid1.
Add manpages.debian.org as a man citeref "project", so we can refer to man
pages hosted there. resolvconf(8) doesn't seem to appear on any of the ones we
currently have defined.
We are doing a trick, where our man page is installed as resolvconf(1), and
we refer the reader to resolvconf(8). This can be pretty confusing, so the
least we can do is to provide a non-broken symlink ;)
v2:
- link to manpages.d.o instead of manpages.ubuntu.com, because debian is the
upstream here, and because with debian we can use /unstable/ as the version,
and ubuntu doesn't seem to have any such shortcut, so the version would need
to be periodically updated.
Yu Watanabe