This way it is more obvious that the queue flag file is always
up-to-date. Moreover, we only have to touch/unlink it when the
first/last event is allocated/freed.
The daemon requires the busname unit to operate (on kdbus systems),
since it contains the policy that allows it to acquire its service
name.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=90287
Given that socket_address_parse() is mostly a "library" call it
shouldn't log on its own, but leave that to its caller.
This patch removes logging from the call in case IPv6 is not available
but and IPv6 address shall be parsed. Instead a new call
socket_address_parse_and_warn() is introduced which first invokes
socket_address_parse() and then logs if necessary.
This should fix "make check" on ipv6-less kernels:
http://lists.freedesktop.org/archives/systemd-devel/2015-April/031385.html
An Exec*= line with whitespace after modifiers, like
ExecStart=- /bin/true
is considered to have an empty command path. This is as specified, but causes
systemd to crash with
Assertion 'skip < l' failed at ../src/core/load-fragment.c:607, function config_parse_exec(). Aborting.
Aborted (core dumped)
Fix this by logging an error instead and ignoring the invalid line.
Add corresponding test cases. Also add a test case for a completely empty value
which resets the command list.
https://launchpad.net/bugs/1454173
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#6 0x562a83aae1af in main src/timedate/timedated.c:730
#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
This means any existing enabled units well be preserved and no
pre-created symlinks will be removed. This is done on first boot, when
the assumption is that /etc is not populated at all (no machine-id
setup). For minimal containers that gives a significant first boot
speed up, approximately ~20ms / ~16% in my trials.
This reverts commit 43c6d5abac
(and a small part of 4046d8361c)
It turns out we don't actually need to set the global ip_forward setting.
The only relevant setting is the one on each interface.
What the global toggle actually does is switch forwarding on/off for all
currently present interfaces and change the default for new ones.
That means that by setting the global ip_forward we
- Introduce a race condition, because if the interface with IPForward=yes
is brought up after one with IPForward=no, both will have forwarding
enabled, because the global switch turns it on for all interfaces.
If the other interface comes up first networkd correctly sets forward=0
and it doesn't get overridden.
- Change the forwarding setting for interfaces that networkd is not
configured to touch, even if the user disabled forwarding via sysctl,
either globally or per-interface
As forwarding works fine without this, as long as all relevant interfacest
individually set IPForward=yes: just drop it
This means that non-networkd interfaces use the global default while
networkd interfaces default to off if IPForward isn't given.
Building with address sanitizer enabled on GCC 5.1.x a memory leak
is reported because we never close the bus, fix it by using
cleanup variable attribute.
So far a number of utilities implemented their own calls for this, unify
them in prefix_root() and prefix_roota(). The former uses heap memory,
the latter allocates from the stack via alloca().
Port over most users of a --root= logic.
If systemd is built with GCC address sanitizer or leak sanitizer
the following memory leak ocurs:
May 12 02:02:46 linux.site systemd[326]: =================================================================
May 12 02:02:46 linux.site systemd[326]: ==326==ERROR: LeakSanitizer: detected memory leaks
May 12 02:02:46 linux.site systemd[326]: Direct leak of 101 byte(s) in 3 object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5336 in strv_new_ap src/shared/strv.c:163
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: Direct leak of 29 byte(s) in 1 object(s) allocated from:
May 12 02:02:46 linux.site systemd[326]: #0 0x7fd1f504993f in strdup (/usr/lib64/libasan.so.2+0x6293f)
May 12 02:02:46 linux.site systemd[326]: #1 0x55d6ffac5288 in strv_new_ap src/shared/strv.c:152
May 12 02:02:46 linux.site systemd[326]: #2 0x55d6ffac56a9 in strv_new src/shared/strv.c:185
May 12 02:02:46 linux.site systemd[326]: #3 0x55d6ffa80272 in generator_paths src/shared/path-lookup.c:223
May 12 02:02:46 linux.site systemd[326]: #4 0x55d6ff9bdb0f in manager_run_generators src/core/manager.c:2828
May 12 02:02:46 linux.site systemd[326]: #5 0x55d6ff9b1a10 in manager_startup src/core/manager.c:1121
May 12 02:02:46 linux.site systemd[326]: #6 0x55d6ff9a78e3 in main src/core/main.c:1667
May 12 02:02:46 linux.site systemd[326]: #7 0x7fd1f394e8c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
May 12 02:02:46 linux.site systemd[326]: SUMMARY: AddressSanitizer: 130 byte(s) leaked in 4 allocation(s).
There is a leak due to the the use of cleanup_free instead _cleanup_strv_free_
If a symlink to a combined cgroup hierarchy already exists and points to
the right path, skip it. This avoids an error when the cgroups are set
manually before calling nspawn.
Previously all bind mount mounts were applied in the order specified,
followed by all tmpfs mounts in the order specified. This is
problematic, if bind mounts shall be placed within tmpfs mounts.
This patch hence reworks the custom mount point logic, and alwas applies
them in strict prefix-first order. This means the order of mounts
specified on the command line becomes irrelevant, the right operation
will always be executed.
While we are at it this commit also adds native support for overlayfs
mounts, as supported by recent kernels.
=================================================================
==64281==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f623c961c4a in malloc (/usr/lib64/libasan.so.2+0x96c4a)
#1 0x5651f79ad34e in malloc_multiply (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2134e)
#2 0x5651f79b02d6 in strjoin (/home/crrodriguez/scm/systemd/systemd-modules-load+0x242d6)
#3 0x5651f79be1f5 in files_add (/home/crrodriguez/scm/systemd/systemd-modules-load+0x321f5)
#4 0x5651f79be6a3 in conf_files_list_strv_internal (/home/crrodriguez/scm/systemd/systemd-modules-load+0x326a3)
#5 0x5651f79bea24 in conf_files_list_nulstr (/home/crrodriguez/scm/systemd/systemd-modules-load+0x32a24)
#6 0x5651f79ad01a in main (/home/crrodriguez/scm/systemd/systemd-modules-load+0x2101a)
#7 0x7f623c11586f in __libc_start_main (/lib64/libc.so.6+0x2086f)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
This happens due to the wrong cleanup attribute is used (free vs strv_free)
