We had two very similar functions: device_read_db_aux and device_read_db,
and a number of wrappers for them:
device_read_db_aux
← device_read_db (in sd-device.c)
← all functions in sd-device.c, including sd_device_is_initialized
← device_read_db_force
← event_execute_rules_on_remove (in udev-event.c)
device_read_db (in device-private.c)
← functions in device_private.c (but not device_read_db_force):
device_get_devnode_{mode,uid,gid}
device_get_devlink_priority
device_get_watch_handle
device_clone_with_db
← called from udevadm, udev-{node,event,watch}.c
Before 7141e4f62c (sd-device: don't retry loading
uevent/db files more than once), the two implementations were the same. In that
commit, device_read_db_aux was changed. Those changes were reverted in the parent
commit, so the two implementations are now again the same except for superficial
differences. This commit removes device_read_db (in sd-device.c), and renames
device_read_db_aux to device_read_db_internal and makes everyone use this one
implementation. There should be no functional change.
This mostly reverts "sd-device: don't retry loading uevent/db files more than
once", 7141e4f62c. We will retry if we couldn't
access the file, but not if parsing failed.
Not re-reading the database at all just doesn't seem like a good idea. We have
two implementations of device_read_db, and one does that, and the other retries
to read the db. Re-reading seems more useful, since we can create the object
and then access properties as some later time when we know that the device has
been initialized and we can get useful results. Otherwise, we force the user to
destroy this object and create a new one.
This changes device_read_uevent_file() and device_read_db_aux(). See next
commit for description of where those functions are used.
If we create 2000 mounts (on a 1-CPU qemu VM) with
mkdir -p /MNT/{1..2000}
time for i in {1..2000}; do mount --bind /etc /MNT/$i ; done
it takes around 20 seconds to complete. Much of this time is taken up
by systemd repeatedly processing /proc/self/mountinfo.
If I disable the processing, the time drops to about 4 seconds.
I have reports that on a larger system with multiple active user sessions, each
with it's own systemd, the impact can be higher.
One particular use-case where a large number of mounts can be expected in quick
succession is when the "clearcase" SCM starts up.
This patch modifies the handling up events from /proc/self/mountinfo so
that systemd backs off when a storm is detected. Specifically the time to process
mountinfo is measured, and the process will not be repeated until 10 times
that duration has passed. This ensures systemd won't use more than 10% of
real time processing mountinfo.
With this patch, my test above takes about 5 seconds.
This reverts commit dd102e4d0c.
That test case exposed a memory leak and breaks CI, so let's revert it until
the original issue is fixed, to prevent disruption of automated testing.
Let's make sure the first hashmap we destroy also frees all machines,
because otherwise when freeing the other hashmaps we'll try to
deregister the contained machines from the hashmaps already destroyed.
Apparently, people do use nscd, hence play somewhat nice with it, and
let's explicitly flush nscd caches whenever we register a new
user/group.
This patch only adds the actual refresh request invocation. Later
commits then issue this call at appropriate moments.
Note that the nscd protocol is not officially documented though very
simple. This code is written very defensively so that incompatibilities
don't affect us much.
Given that glibc really has a duty to maintain compat between
differently compiled programs and their system nscd they can't break API
and thus it should be safe for us to implement an alternative,
minimalistic client.
Ideally this kind of explicit, global cache flushing would not be necessary.
However nscd currently has no cache coherency protocol, hence we can't
really implement this better. The only concept it knows is a TTL for
positive hosts lookups. Hoewver for negative lookups or any of the other
tables nothing is available.
The ?: operator is very useful for chaining comparison functions
(strcmp, memcmp, CMP), since its behavior is to return the result
of the comparison function call if non-zero, or continue evaluating
the chain of comparison functions.
This simplifies the code in that using a temporary `r` variable
to store the function results is no longer necessary and the checks
for non-zero to return are no longer needed either, resulting in a
typical three-fold reduction to the number of lines in the code.
Introduce a new memcmp_nn() to compare two memory buffers in
lexicographic order, taking length in consideration.
Tested: $ ninja -C build/ test
All test cases pass. In particular, test_multiple_neighbors_sorted()
in test-lldp would catch regressions introduced by this commit.
In particular, check that the order of the results is consistent.
This test coverage will be useful in order to refactor the compare_func
used while sorting the results.
Tested: ninja -C build/ test
This is mostly paranoia, but let's better be safer than sorry. This of
course means there's always an implicit limit to how much we can read at
a time of 2G. But that should be ample.
From WordNet (r) 3.0 (2006) [wn]:
time-out
n 1: a brief suspension of play; "each team has two time-outs left"
From The Free On-line Dictionary of Computing (18 March 2015) [foldoc]:
timeout
A period of time after which an error condition is raised if
some event has not occured. A common example is sending a
message. If the receiver does not acknowledge the message
within some preset timeout period, a transmission error is
assumed to have occured.
u32ctz() was undefined for zero due to __builtin_ctz() [1].
Explicitly check for zero to make the behavior defined.
Note that this issue only affected in4_addr_netmask_to_prefixlen()
which is the only caller.
It may seem slightly odd, to return 32 (bits) for utz(0). But that
is what in4_addr_netmask_to_prefixlen() needs, and it probably makes
the most sense here.
[1] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Fixes: ba91431154
This has been irritating me for quite a while: let's prefix these enum
values with a common prefix, like we do for almost all other enums.
No change in behaviour, just some renaming.
From the results of CIs in #11076, changing buffer size may cause
issue #10754. So, let's prohibit to change the size if it is already
bound.
This also reverts commit 986ab0d2dc.
If the socket fd is passed by PID1, then it is created by .socket unit
and we have already set sufficient option(s) for the socket.
So, let's not touch the passed socket.
In #10583, a unit file lives in ~/.config/systemd/user, and
'systemctl --runtime --user mask' is used to create a symlink in /run.
This symlink has lower priority than the config file, so
'systemctl --user' will happily load the unit file, and does't care about
the symlink at all.
But when asked if the unit is enabled, we'd look for all symlinks, find the
symlink in the runtime directory, and report that the unit is runtime-enabled.
In this particular case the fact that the symlink points at /dev/null, creates
additional confusion, but it doesn't really matter: *any* symlink (or regular
file) that is lower in the priority order is "covered" by the unit fragment,
and should be ignored.
Fixes#10583.
If the terminal is in graphical mode, the kernel will refuse to copy the fonts
and will return -EINVAL.
Also having the graphical mode in effect probably indicates that the terminal
is in used by another application and we shouldn't interfer in such cases.
The name argument in UnitFileInstallInfo (i->name) should always be a unit
file name, so the conditional always takes the 'else' branch.
The only call chain that links to find_symlinks_fd() is unit_file_lookup_state
→ find_symlinks_in_scope → find_symlinks → find_symlinks_fd. But
unit_file_lookup_state calls unit_name_is_valid(name), and then name is used
to construct the UnitFileInstallInfo object in install_info_discover, which just
uses the name it was given.
It would work when the generator was run by systemd, since generators
are always started in "/", but when running the generator for debugging
purposes the result would be ... different.
There should be no functional difference, except that the error message
is changd from "three or no arguments" to "zero or three arguments". Somehow
the inverted form always seemed strange.
umask() call is also dropped from run-generator. I think it wasn't dropped in
053254e3cb because the run generator was merged
around the same time.
RFC7766 section 4 states that in the absence of EDNS0, a response that
is too large for a 512-byte UDP packet will have the 'truncated' bit
set. The client is expected to retry the query over TCP.
Fixes#10264.
The parent slice is always filtered ahead of time from UNIT_BEFORE, so
checking if the current member is the same as the parent unit will never
pass.
I may also write a SLICE_FOREACH_CHILD macro to remove some more of the
parent slice checks, but this requires a bit of a rework and general
refactoring and may not be worth it, so let's just do this for now.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
NeilBrown
Lennart Poettering
Filipe Brandenburger
Susant Sahani
Thomas Haller
Franck Bui
Chris Down
Sam Morris