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
We ask for the TTL, then have enough space for it.
We probably can drop the extra cmsg space now, but let's figure that out
another time, since the extra cmsg space is used elsewhere in resolved
as well.
udev: when the BSD lock on a block device is taken, don't complain
if someone implements https://systemd.io/BLOCK_DEVICE_LOCKING/ then we
shouldn't loudly complain about that.
This reverts back to the original behaviour from 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d: when the lock is taken we
silently skip processing the device and sending out the messages for it.
run: when waiting for unit, also check if no job is pending anymore
This is a fix-up for a7c71d214c37797d82de2f66cfe0a0a79c3a5c92: since we
now don't wait for the job to finish anymore right after enqueuing it,
we should not exit our ptyfwd logic before the unit is back to inactive
*and* no job pending anymore.
Chris Down [Tue, 26 May 2020 13:35:18 +0000 (14:35 +0100)]
service: Display updated WatchdogUSec from sd_notify
Suppose a service has WatchdogSec set to 2 seconds in its unit file. I
then start the service and WatchdogUSec is set correctly:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
Now I call `sd_notify(0, "WATCHDOG_USEC=10000000")`. The new timer seems
to have taken effect, since I only send `WATCHDOG=1` every 4 seconds,
and systemd isn't triggering the watchdog handler. However, `systemctl
show` still shows WatchdogUSec as 2s:
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=2s
This seems surprising, since this "original" watchdog timer isn't the
one taking effect any more. This patch makes it so that we instead
display the new watchdog timer after sd_notify(WATCHDOG_USEC):
% systemctl --user show psi-notify -p WatchdogUSec
WatchdogUSec=10s