| Age | Commit message (Collapse) | Author |
|---|
|
dbus-daemon currently uses a backlog of 30 on its D-bus system bus socket. On
overloaded systems this means that only 30 connections may be queued without
dbus-daemon processing them before further connection attempts fail. Our
cgroups-agent binary so far used D-Bus for its messaging, and hitting this
limit hence may result in us losing cgroup empty messages.
This patch adds a seperate cgroup agent socket of type AF_UNIX/SOCK_DGRAM.
Since sockets of these types need no connection set up, no listen() backlog
applies. Our cgroup-agent binary will hence simply block as long as it can't
enqueue its datagram message, so that we won't lose cgroup empty messages as
likely anymore.
This also rearranges the ordering of the processing of SIGCHLD signals, service
notification messages (sd_notify()...) and the two types of cgroup
notifications (inotify for the unified hierarchy support, and agent for the
classic hierarchy support). We now always process events for these in the
following order:
1. service notification messages (SD_EVENT_PRIORITY_NORMAL-7)
2. SIGCHLD signals (SD_EVENT_PRIORITY_NORMAL-6)
3. cgroup inotify and cgroup agent (SD_EVENT_PRIORITY_NORMAL-5)
This is because when receiving SIGCHLD we invalidate PID information, which we
need to process the service notification messages which are bound to PIDs.
Hence the order between the first two items. And we want to process SIGCHLD
metadata to detect whether a service is gone, before using cgroup
notifications, to decide when a service is gone, since the former carries more
useful metadata.
Related to this:
https://bugs.freedesktop.org/show_bug.cgi?id=95264
https://github.com/systemd/systemd/issues/1961
|
|
Rework DUID setting
|
|
|
|
make virtualization detection quieter, rework unit start limit logic, detect unit file drop-in changes correctly, fix autofs state propagation
|
|
is enabled (#3079)
When ACL support is enabled, systemd-tmpfiles-setup service sets the following
ACL entries to the volatile system journal:
$ getfacl /run/log/journal/*/system.journal
getfacl: Removing leading '/' from absolute path names
# file: run/log/journal/xxx/system.journal
# owner: root
# group: systemd-journal
user::rwx
group::r--
group:wheel:r-x
group:adm:r-x
mask::r-x
other::---
This patch makes sure that the exec bit is not set anymore for the volatile
system journals.
|
|
Fix incorrect string deduplication in udev
|
|
Commit 82501b3fc added an early break when a terminal node is found to
incorrect place -- before setting c. This caused trie to be built that
does not correspond to what it points to in buffer, causing incorrect
deduplications:
# cat /etc/udev/rules.d/99-bug.rules
ENV{FOO}=="0"
ENV{xx0}=="BAR"
ENV{BAZ}=="00"
# udevadm test
* RULE /etc/udev/rules.d/99-bug.rules:1, token: 0, count: 2, label: ''
M ENV match 'FOO' '0'(plain)
* RULE /etc/udev/rules.d/99-bug.rules:2, token: 2, count: 2, label: ''
M ENV match 'xx0' 'BAR'(plain)
* RULE /etc/udev/rules.d/99-bug.rules:3, token: 4, count: 2, label: ''
M ENV match 'BAZ' 'x0'(plain)
* END
The addition of "xx0" following "0" will cause a trie like this to be
created:
c=\0
c=0 "0"
c=0 "xx0" <-- note the c is incorrect here, causing "00" to be
c=O "FOO" deduplicated to it
c=R "BAR"
This in effect caused the usb_modeswitch rule for Huawei modems to never
match and this never be switched to serial mode from mass storage.
|
|
Alternatively, this could perhaps be removed since it was broken for a
long time and noone seemed to care.
But it was helpful for me today.
|
|
install: cache the presets before evaluating
|
|
Closes #2166.
We only allow 0, infinity and forever.
infinity and forever is same.
|
|
networkd: add support to set route table
|
|
Dnssec incapdns fix
|
|
The previous implementation traversed the various config directories,
walking the preset files and parsing each line to determine if a service
should be enabled or disabled. It did this for every service which
resulted in many more file operations than neccessary.
This approach parses each of the preset entries into an array which is
then used to check if each service should be enabled or disabled.
|
|
(zjs: the tree is now back to 0b2abe0f034f7f2d8654adb11b516d1090ec9a9c.)
|
|
|
|
This reverts commit 6d10d308c6cd16528ef58fa4f5822aef936862d3.
It got squashed by mistake.
|
|
This reverts commit 0bed31c1038c439cc5956fb44017ba28e503095b.
|
|
|
|
This reverts commit d2773e59de3dd970d861e9f996bc48de20ef4314.
Merge got squashed by mistake.
|
|
networkd: add support to set route table
1. add support to configure the table id.
if id is less than 256 we can fit this in the header of route as
netlink property is a char. But in kernel this proepty is a
unsigned 32. Hence if greater that 256 add this as RTA_TABLE
attribute.
2. we are not setting the address family now. Now set this property.
|
|
Introduce
1. sd_rtnl_message_route_set_table to set table ID
2. sd_rtnl_message_route_set_family to set family
Both required to configure route properties.
|
|
Also remove the braces add_rtattr not required.
|
|
It wasn't used for anything after the recent changes.
|
|
This is essentially a revert of f38e0cce75ff2ffbd99f7e382ed39c160bb7d799 (which
removed the documentation of DUIDType on purpose). The description is heavily
updated for the new semantics.
This addresses #3127 § 4.
|
|
|
|
|
|
Separate fields are replaced with a struct.
Second second duid type field is removed. The first field was used to carry
the result of DUIDType= configuration, and the second was either a copy of
this, or contained the type extracted from DuidRawData. The semantics are changed
so that the type specified in DUIDType is always used. DUIDRawData= no longer
overrides the type setting.
The networkd code is now more constrained than the sd-dhcp code:
DUIDRawData cannot have 0 length, length 0 is treated the same as unsetting.
Likewise, it is not possible to set a DUIDType=0. If it ever becomes necessary
to set type=0 or a zero-length duid, the code can be changed to support that.
Nevertheless, I think that's unlikely.
This addresses #3127 § 1 and 3.
v2:
- rename DUID.duid, DUID.duid_len to DUID.raw_data, DUID.raw_data_len
|
|
Both versions of the code are changed to allow the caller to override
DUID using simple rules: duid type and value may be specified, in
which case the caller is responsible to providing the contents,
or just duid type may be specified as DUID_TYPE_EN, in which case we
we fill in the values. In the future more support for other types may
be added, e.g. DUID_TYPE_LLT.
There still remains and ugly discrepancy between dhcp4 and dhcp6 code:
dhcp6 has sd_dhcp6_client_set_duid and sd_dhcp6_client_set_iaid and
requires client->state to be DHCP6_STATE_STOPPED, while dhcp4 has
sd_dhcp_client_set_iaid_duid and will reconfigure the client if it
is not stopped. This commit doesn't touch that part.
This addresses #3127 § 2.
|
|
After all it is used in more than one place and is not that short.
Also tweak the test a bit:
- do not check that duid_len > 0, because we want to allow unknown
duid types, and there might be some which are fine with 0 length data,
(also assert should not be called from library code),
- always check that duid_len <= MAX_DUID_LEN, because we could overwrite
available buffer space otherwise.
|
|
|
|
|
|
|
|
[/etc/systemd/system/test.socket:2] Unknown lvalue 'TriggerLimitIntervalBurst' in section 'Socket'
Follow-up for 8b26cdbd2a94
|
|
|
|
Refuse Alias, DefaultInstance, templated units in install (as appropriate)
|
|
machined: make "clone" asynchronous, and support copy-based fall-back
|
|
|
|
incapdns.net returns NXDOMAIN for the SOA of the zone itself but is not a
terminal. This is against the specs, but we really should be able to deal with
this.
Previously, when verifying whether an NXDOMAIN response for a SOA/NS lookup is
rightfully unsigned we'd issue a SOA lookup for the parent's domain, to derive
the state from that. If the parent SOA would get an NXDOMAIN, we'd continue
upwards, until we hit a signed top-level domain, which suggests that the domain
actually exists.
With this change whenver we need to authenticate an NXDOMAIN SOA reply, we'll
request the DS RR for the zone first, and use for validation, since that this
must be from the parent's zone, not the incorrect lower zone.
Fixes: #2894
|
|
that way we can be sure that there's no expiry timeout in place at any time
when we aren't in the RUNNING state.
|
|
Port the progagation logic to the generic Unit->trigger_notify() callback logic
in the unit vtable, that is called for a unit not only when the triggered unit
of it changes state but also when a job for that unit finishes. This, firstly
allows us to make the code a bit cleaner and more generic, but more
importantly, allows us to notice correctly when a mount job fails, and
propagate that back to autofs client processes.
Fixes: #2181
|
|
job for the service queued
|
|
We already did this for the [Mount] section, let's do the same for [Automount].
|
|
|
|
Also, fix indentation.
|
|
And let's make it more accurate: if we have acquire the list of unit drop-ins,
then let's do a full comparison against the old list we already have, and if
things differ in any way, we know we have to reload.
This makes sure we detect changes to drop-in directories in more cases.
|
|
This fixes fall-out from 6d10d308c6cd16528ef58fa4f5822aef936862d3.
Until that commit, do determine whether a daemon reload was required we compare
the mtime of the main unit file we loaded with the mtime of it on disk for
equality, but for drop-ins we only stored the newest mtime of all of them and
then did a "newer-than" comparison. This was brokeni with the above commit,
when all checks where changed to be for equality.
With this change all checks are now done as "newer-than", fixing the drop-in
mtime case. Strictly speaking this will not detect a number of changes that the
code before above commit detected, but given that the mtime is unlikely to go
backwards, and this is just intended to be a helpful hint anyway, this looks OK
in order to keep things simple.
Fixes: #3123
|
|
Let's move the enforcement of the per-unit start limit from unit.c into the
type-specific files again. For unit types that know a concept of "result" codes
this allows us to hook up the start limit condition to it with an explicit
result code. Also, this makes sure that the state checks in clal like
service_start() may be done before the start limit is checked, as the start
limit really should be checked last, right before everything has been verified
to be in order.
The generic start limit logic is left in unit.c, but the invocation of it is
moved into the per-type files, in the various xyz_start() functions, so that
they may place the check at the right location.
Note that this change drops the enforcement entirely from device, slice, target
and scope units, since these unit types generally may not fail activation, or
may only be activated a single time. This is also documented now.
Note that restores the "start-limit-hit" result code that existed before
6bf0f408e4833152197fb38fb10a9989c89f3a59 already in the service code. However,
it's not introduced for all units that have a result code concept.
Fixes #3166.
|
|
This is hardly useful, it's trivial for developers to get that info by running
cat /proc/cpuinfo.
Fixes #3155
|
|
|
|
|
