Instead of reading the mtime off the configuration files after reading,
let's do so before reading, but with the fd we read the data from. This
is not only cleaner (as it allows us to save one stat()), but also has
the benefit that we'll detect changes that happen while we read the
files.
This also reworks unit file drop-ins to use the common code for
determining drop-in mtime, instead of reading system clock for that.
> [kernel uses] msleep_interruptible() and that means when the process receives
> any kind of signal masked or not this will abort with EINTR. systemd-logind
> gets signals from the TTY layer all the time though.
> Here's what might be happening: while logind reads the EFI stuff it gets a
> series of signals from the TTY layer, which causes the read() to be aborted
> with EINTR, which means logind will wait 50ms and retry. Which will be
> aborted again, and so on, until quite some time passed. If we'd not wait for
> the 50ms otoh we wouldn't wait so long, as then on each signal we'd
> immediately retry again.
Luca Boccassi [Mon, 1 Jun 2020 11:24:10 +0000 (12:24 +0100)]
test: temporarily block test 48 on Ubuntu's autopkgtest
This test runs fine locally (both on Qemu and nspawn) but sporadically fails on
autopkgtest for some reason.
Disable it while the issue is investigated to reduce noise.
basic/user-util: always use base 10 for user/group numbers
We would parse numbers with base prefixes as user identifiers. For example,
"0x2b3bfa0" would be interpreted as UID==45334432 and "01750" would be
interpreted as UID==1000. This parsing was used also in cases where either a
user/group name or number may be specified. This means that names like
0x2b3bfa0 would be ambiguous: they are a valid user name according to our
documented relaxed rules, but they would also be parsed as numeric uids.
This behaviour is definitely not expected by users, since tools generally only
accept decimal numbers (e.g. id, getent passwd), while other tools only accept
user names and thus will interpret such strings as user names without even
attempting to convert them to numbers (su, ssh). So let's follow suit and only
accept numbers in decimal notation. Effectively this means that we will reject
such strings as a username/uid/groupname/gid where strict mode is used, and try
to look up a user/group with such a name in relaxed mode.
Since the function changed is fairly low-level and fairly widely used, this
affects multiple tools: loginctl show-user/enable-linger/disable-linger foo',
the third argument in sysusers.d, fourth and fifth arguments in tmpfiles.d,
etc.
Luca Boccassi [Thu, 7 May 2020 22:26:53 +0000 (23:26 +0100)]
core: reload cache if it's dirty when starting a UNIT_NOT_FOUND unit
The time-based cache allows starting a new unit without an expensive
daemon-reload, unless there was already a reference to it because of
a dependency or ordering from another unit.
If the cache is out of date, check again if we can load the
fragment.
This is an attempt to clean-up the DHCP lease server type code a bit. We
now strictly use the same enum everywhere, and store server info in an
array. Moreover, we use the same nomenclature everywhere.
This only makes the changes in the sd-dhcp code. The networkd code is
untouched so far (but should be fixed up like this too. But it's more
complicated since this would then touch actual settings in .network
files).
Note that this also changes some field names in serialized lease files.
But given that these field names have not been part of a released
version of systemd yet, such a change should be ok.
This is pure renaming/refactoring, shouldn't actually change any
behaviour.
Susant Sahani [Sat, 30 May 2020 04:35:28 +0000 (06:35 +0200)]
network: L2TP fix crash
```
=220358== Invalid read of size 8
==220358== at 0x452F05: l2tp_session_free (l2tp-tunnel.c:46)
==220358== by 0x456926: l2tp_tunnel_done (l2tp-tunnel.c:725)
==220358== by 0x43CF4D: netdev_free (netdev.c:205)
==220358== by 0x43D045: netdev_unref (netdev.c:210)
==220358== by 0x4198B7: manager_free (networkd-manager.c:1877)
==220358== by 0x40D0B3: manager_freep (networkd-manager.h:105)
==220358== by 0x40DE1C: run (networkd.c:21)
==220358== by 0x40DE75: main (networkd.c:130)
==220358== Address 0x5c035d0 is 0 bytes inside a block of size 40 free'd
==220358== at 0x483A9F5: free (vg_replace_malloc.c:538)
==220358== by 0x452F87: l2tp_session_free (l2tp-tunnel.c:57)
==220358== by 0x456857: netdev_l2tp_tunnel_verify (l2tp-tunnel.c:710)
==220358== by 0x440947: netdev_load_one (netdev.c:738)
==220358== by 0x441222: netdev_load (netdev.c:851)
==220358== by 0x419C50: manager_load_config (networkd-manager.c:1934)
==220358== by 0x40D7BE: run (networkd.c:87)
==220358== by 0x40DE75: main (networkd.c:130)
==220358== Block was alloc'd at
==220358== at 0x4839809: malloc (vg_replace_malloc.c:307)
==220358== by 0x452A76: malloc_multiply (alloc-util.h:96)
==220358== by 0x4531E6: l2tp_session_new_static (l2tp-tunnel.c:82)
==220358== by 0x455C01: config_parse_l2tp_session_id (l2tp-tunnel.c:535)
==220358== by 0x48E6D72: next_assignment (conf-parser.c:133)
==220358== by 0x48E77A3: parse_line (conf-parser.c:271)
==220358== by 0x48E7E4F: config_parse (conf-parser.c:396)
==220358== by 0x48E80E5: config_parse_many_files (conf-parser.c:453)
==220358== by 0x48E8490: config_parse_many (conf-parser.c:512)
==220358== by 0x44089C: netdev_load_one (netdev.c:729)
==220358== by 0x441222: netdev_load (netdev.c:851)
==220358== by 0x419C50: manager_load_config (networkd-manager.c:1934)
efi: as extra paranoia NUL terminate UTF-16 strings with three NUL bytes
This is a safey net anyway, let's make it fully safe: if the data ends
on an uneven byte, then we need to complete the UTF-16 codepoint first,
before adding the final NUL byte pair. Hence let's suffix with three
NULs, instead of just two.
Figure 30: Vendor-specific Information Option Format
option-code OPTION_VENDOR_OPTS (17).
option-len 4 + length of vendor-option-data field.
enterprise-number The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet
field containing an unsigned integer.
vendor-option-data Vendor options, interpreted by
vendor-specific code on the clients and
servers. A variable-length field (4 octets
less than the value in the option-len field).
The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field.
Use of vendor-specific information allows enhanced operation,
utilizing additional features in a vendor's DHCP implementation. A
DHCP client that does not receive requested vendor-specific
information will still configure the node's IPv6 stack to be
functional.
The vendor-option-data field MUST be encoded as a sequence of
code/length/value fields of format identical to the DHCP options (see
Section 21.1). The sub-option codes are defined by the vendor
identified in the enterprise-number field and are not managed by
IANA. Each of the sub-options is formatted as follows:
sub-opt-code The code for the sub-option. A 2-octet
field.
sub-option-len An unsigned integer giving the length of the
sub-option-data field in this sub-option in
octets. A 2-octet field.
sub-option-data The data area for the sub-option. The
length, in octets, is specified by
sub-option-len.
Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the
Enterprise Number in that option. Servers and clients MUST NOT send
more than one instance of the Vendor-specific Information option with
the same Enterprise Number. Each instance of the Vendor-specific
Information option MAY contain multiple sub-options.
A client that is interested in receiving a Vendor-specific
Information option:
- MUST specify the Vendor-specific Information option in an Option
Request option.
- MAY specify an associated Vendor Class option (see Section 21.16).
- MAY specify the Vendor-specific Information option with
appropriate data.
Servers only return the Vendor-specific Information options if
specified in Option Request options from clients and:
- MAY use the Enterprise Numbers in the associated Vendor Class
options to restrict the set of Enterprise Numbers in the
Vendor-specific Information options returned.
- MAY return all configured Vendor-specific Information options.
- MAY use other information in the packet or in its configuration to
determine which set of Enterprise Numbers in the Vendor-specific
Information options to return.
network: DHCPv6 Assign delegated prefix to LAN interface
In DHCPv6-PD environment, where WAN interface requests IPv6 via DHCPv6,
receives the address as well as delegated prefixes, with LAN interfaces
serving those delegated prefixes in their router advertisement messages.
The LAN interfaces on the router themselves do not have
the IPv6 addresses assigned by networkd from the prefix it
serves on that interface. Now this patch enables it.
sd-network: Rectify Advertise Message Processing by a Client
We need to fix RCC 2215 behaviour with rfc7550 errata
and https://tools.ietf.org/html/rfc8415.
[RFC3315] specifies that a client must ignore an Advertise message if
a server will not assign any addresses to a client, and [RFC3633]
specifies that a client must ignore an Advertise message if a server
returns the NoPrefixAvail status to a requesting router. Thus, a
client requesting both IA_NA and IA_PD, with a server that only
offers either addresses or delegated prefixes, is not supported by
the current protocol specifications.
Solution: a client SHOULD accept Advertise messages, even when not
all IA option types are being offered. And, in this case, the client
SHOULD include the not offered IA option types in its Request. A
client SHOULD only ignore an Advertise message when none of the
requested IA options include offered addresses or delegated prefixes.
Note that ignored messages MUST still be processed for SOL_MAX_RT and
INF_MAX_RT options as specified in [RFC7083].
Replace Section 17.1.3 of RFC 3315: (existing errata)
The client MUST ignore any Advertise message that includes a Status
Code option containing the value NoAddrsAvail, with the exception
that the client MAY display the associated status message(s) to the
user.
With the following text (which addresses the existing erratum
[Err2471] and includes the changes made by [RFC7083]):
The client MUST ignore any Advertise message that contains no
addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
options; see RFC 3633) with the exception that the client:
- MUST process an included SOL_MAX_RT option (RFC 7083) and
- MUST process an included INF_MAX_RT option (RFC 7083).
A client can display any associated status message(s) to the user
or activity log.
The client ignoring this Advertise message MUST NOT restart the
Solicit retransmission timer.
sd-device: check netlink netns matches host netns before using monitor
Tracking down #15931 confused the hell out of me, since running homed in
gdb from the command line worked fine, but doing so as a service failed.
Let's make this more debuggable and check if we live in the host netns
when allocating a new udev monitor.
This is just debug stuff, so that if things don't work, a quick debug
run will reveal what is going on.
That said, while we are at it, also fix unexpected closing of passed in
fd when failing.
sd-path: drop "-dir" and "-path" suffixes from path enums
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.
Strictly speaking you can run homed without userdb. But it doesn't
really make much sense: they go hand in hand and implement the same
concepts, just for different sets of users. Let's hence disable both
automatically by default if homed is requested.
(We don't do the reverse: opting into userdbd shouldn't mean that you
are OK with homed.)
And of course, users can always deviate from our defaults easily, and
turn off userbd again right-away if they don't like it, and things will
generally work.
manager: free the jobs hashmap after we have no jobs
After a larger transaction, e.g. after bootup, we're left with an empty hashmap
with hundreds of buckets. Long-term, it'd be better to size hashmaps down when
they are less than 1/4 full, but even if we implement that, jobs hashmap is
likely to be empty almost always, so it seems useful to deallocate it once the
jobs count reaches 0.
shared/unit-file: make sure the old hashmaps and sets are freed upon replacement
Possibly fixes #15220. (There might be another leak. I'm still investigating.)
The leak would occur when the path cache was rebuilt. So in normal circumstances
it wouldn't be too bad, since usually the path cache is not rebuilt too often. But
the case in #15220, where new unit files are created in a loop and started, the leak
occurs once for each unit file:
$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service ~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user start test$(printf %04d $i).service;done
projects / thirdparty / systemd.git / log
