| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This way they always show up together with 'Found ordering cycle...'.
Ordering cycles are a serious error and a major pain to debug. If
quiet is enabled, only the first and the last line of output are
shown:
systemd[1]: Found ordering cycle on basic.target/start
systemd[1]: Breaking ordering cycle by deleting job timers.target/start
systemd[1]: Job timers.target/start deleted to break ordering cycle starting with basic.target/start
which isn't particularly enlightening. So just show the whole message
at the same level.
https://bugzilla.redhat.com/show_bug.cgi?id=1158206
|
|
|
|
This library negotiates a PPPoE channel. It handles the discovery stage and
leaves the session stage to the kernel. A further PPP library is needed to
actually set up a PPP unit (negotatie LCP, IPCP and do authentication), so in
isolation this is not yet very useful.
The test program has two modes:
# ./test-pppoe
will create a veth tunnel in a new network namespace, start pppoe-server on one
end and this client library on the other. The pppd server will time out as no
LCP is performed, and the client will then shut down gracefully.
# ./test-pppoe eth0
will run the client on eth0 (or any other netdev), and requires a PPPoE server
to be reachable on the local link.
|
|
FILE * wants cleanup_fclose().
Spotted by udev hwdb segfaulting in gnome-continuous' buildroot
construction.
|
|
s/threat/treat/g
|
|
A recent commit (2f3a215) changed the parsing of /proc/cmdline to use a
shell array. Unfortunately, this introduced a bug: "read -ar line"
populates the shell variable $r, not $line. This breaks installation of
new loader entries:
# kernel-install add 3.17.1-304.fc21.x86_64 \
/boot/vmlinuz-3.17.1-304.fc21.x86_64
Could not determine the kernel command line parameters.
Please specify the kernel command line in /etc/kernel/cmdline!
This commit alters the read command to correctly populate the $line
array instead.
|
|
|
|
|
|
The duid data passed by the caller does not include the DUID type,
but sd_dhcp6_client_set_duid() was treating it like it did.
|
|
|
|
The term "priority" is misleading because higher levels have lower
priority. "Level" is clearer and shorter.
This commit touches only the textual descriptions, not function and variable
names themselves. "Priority" is used in various command-line switches and
protocol constants, so completly getting rid of "priority" is hard.
I also left "priority" in various places where the clarity suffered
when it was removed.
|
|
Invalid log levels lead to a assert failure later on.
https://bugs.freedesktop.org/show_bug.cgi?id=85657
|
|
This brings udev logging style a bit closer to normal systemd convention.
|
|
Also change the default prefixlen function to only access the first octet of the in_addr.
|
|
|
|
|
|
|
|
|
|
event loop
We really should not run manual event loops anymore, but standardize on
sd_event, so that we can run sd_bus connections from it eventually.
|
|
__attribute__((used)) is not enough to force static variables to
be carried over to a compiled program from a library. Mappings defined
in libsystemd-shared.a were not visible in the compiled binaries.
To ensure that the mappings are present in the final binary, the
tables are made non-static and are given a real unique name by which
they can be referenced.
To use a mapping defined not in the local compilation unit (e.g. in
a library) a reference to the mapping table is added. This is done
by including a declaration in the header file.
Expected values in test-engine are fixed to reflect the new mappings.
|
|
Depending on the link order, holes might appear in the body of
the sd_bus_errnomap section. Ignore them.
Adds a simple test to print the table to help with debugging such
issues in the future.
|
|
Instead, only depend on the actual file systems we need.
This should solve dep loops on setups where remote-fs.target is moved
into late boot.
|
|
|
|
f7101b7368df copied some logic to prevent enabling masked units, but
also added a check which causes attempts to enable templated units to
fail. Since we know the logic beyond this check will properly handle
units which truly do not exist, we can rely on the unit file state
comparison to suffice for expressing the intent of f7101b7368df.
ref: https://bugs.archlinux.org/task/42616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add tests for:
- strv_find_startswith
- strv_push_prepend
- strv_consume_prepend
|
|
add tests for the following functions:
- write_string_file_no_create
- load_env_file_pairs
|
|
The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired. Clean it up properly so we're
not still listening and responding to events on it.
|
|
|
|
I tried to preserve most errno values, but in some cases they were
inconsistent (different errno values for the same error name) or just
mismatched.
|
|
This allows custom "name" ↔ errno mappings to be registered.
Tables from all compilation units are concatenated.
|
|
|
|
This is a rewrite of the hashmap implementation. Its advantage is lower
memory usage.
It uses open addressing (entries are stored in an array, as opposed to
linked lists). Hash collisions are resolved with linear probing and
Robin Hood displacement policy. See the references in hashmap.c.
Some fun empirical findings about hashmap usage in systemd on my laptop:
- 98 % of allocated hashmaps are Sets.
- Sets contain 78 % of all entries, plain Hashmaps 17 %, and
OrderedHashmaps 5 %.
- 60 % of allocated hashmaps contain only 1 entry.
- 90 % of allocated hashmaps contain 5 or fewer entries.
- 75 % of all entries are in hashmaps that use trivial_hash_ops.
Clearly it makes sense to:
- store entries in distinct entry types. Especially for Sets - their
entries are the most numerous and they require the least information
to store an entry.
- have a way to store small numbers of entries directly in the hashmap
structs, and only allocate the usual entry arrays when the direct
storage is full.
The implementation has an optional debugging feature (enabled by
defining the ENABLE_HASHMAP_DEBUG macro), where it:
- tracks all allocated hashmaps in a linked list so that one can
easily find them in gdb,
- tracks which function/line allocated a given hashmap, and
- checks for invalid mixing of hashmap iteration and modification.
Since entries are not allocated one-by-one anymore, mempools are not
used for entries. Originally I meant to drop mempools entirely, but it's
still worth it to use them for the hashmap structs. My testing indicates
that it makes loading of units about 5 % faster (a test with 10000 units
where more than 200000 hashmaps are allocated - pure malloc: 449±4 ms,
mempools: 427±7 ms).
Here are some memory usage numbers, taken on my laptop with a more or
less normal Fedora setup after booting with SELinux disabled (SELinux
increases systemd's memory usage significantly):
systemd (PID 1) Original New Change
dirty memory (from pmap -x 1) [KiB] 2152 1264 -41 %
total heap allocations (from gdb-heap) [KiB] 1623 756 -53 %
|
|
A reimplementation of hashmaps will follow and it will use 0.8.
|
|
Add mempool_alloc0_tile(). It's like mempool_alloc_tile(), but it
initializes the allocated tile's memory to zero.
|
|
Two's logarithms for unsigned.
|
|
provided headers
|
|
|
|
|
|
in /dev/shm
Previously when a log message grew beyond the maximum AF_UNIX/SOCK_DGRAM
datagram limit we'd send an fd to a deleted file in /dev/shm instead.
Because the sender could still modify the file after delivery we had to
immediately copy the data on the receiving side.
With memfds we can optimize this logic, and also remove the dependency
on /dev/shm: simply send a sealed memfd around, and if we detect the
seal memory map the fd and use it directly.
|
|
We really shouldn't create fds ever that have the flag unset.
|
|
|
|
|
