pid1: fix cleanup of stale implicit deps based on /proc/self/mountinfo
The problem was introduced in a37422045fbb68ad68f734e5dc00e0a5b1759773:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
on it are dropped.
The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.
units: drop conditionalization of systemd-tmpfiles-setup-dev.service
Currently, tmpfiles runs in two separate services at boot. /dev is
populated by systemd-tmpfiles-setup-dev.service and everything else by
systemd-tmpfiles-setup.service. The former was so far conditionalized by
CAP_SYS_MODULES. The reasoning was that the primary purpose of
populating /dev was to create device nodes based on the static device
node info exported in kernel modules through MODALIAS. And without the
privs to load kernel modules doing so is unnecessary. That thinking is
incomplete however, as there might be reason to create stuff in /dev
outside of the static modalias usecase. Thus, let's drop the
conditionalization to ensure that tmpfiles.d rules are always executed
at least once under all conditions.
journald: periodically drop cache for all dead PIDs
In normal use, this allow us to drop dead entries from the cache and reduces
the cache size so that we don't evict entries unnecessarily. The time limit is
there mostly to serve as a guard against malicious logging from many different
PIDs.
journal: limit the number of entries in the cache based on available memory
This is far from perfect, but should give mostly reasonable values. My
assumption is that if somebody has a few hundred MB of memory, they are
unlikely to have thousands of processes logging. A hundred would already be a
lot. So let's scale the cache size propritionally to the total memory size,
with clamping on both ends.
The formula gives 64 cache entries for each GB of RAM.
The badge is currently serving a broken image, since Coverity Scan is currently
having an outage. See Issue #11185 for more details. We can restore the badge
by reverting this commit once their service is up again.
procfs-util: expose functionality to query total memory
procfs_memory_get_current is renamed to procfs_memory_get_used, because
"current" can mean anything, including total memory, used memory, and free
memory, as long as the value is up to date.
Looks to be additions and corrections again. It seems somebody removed
some whitespace in variuos places by mistake, let's hope this gets corrected
upstream. Doing such corrections downstream is not worth the trouble.
Yu Watanabe [Tue, 22 Jan 2019 02:45:40 +0000 (11:45 +0900)]
sd-device: do not save e.g., DEVPATH or INTERFACE properties to udev database
Previously, device_copy_properties() copies all properties to both
sd_device::properties and ::properties_db. Thus, on move uevent,
also tentative properties, e.g. DEVPATH or INTERFACE, are stored to
::properties_db, and saved to udev database.
This makes such tentative properties be copied to only ::properties,
and thus not saved to udev database.
Yu Watanabe [Fri, 18 Jan 2019 03:55:15 +0000 (12:55 +0900)]
network: unset Network::manager when loading .network file fails
Otherwise, LIST_REMOVE() in network_free() fails.
This fixes the following assertion:
```
systemd-networkd[2595]: Bus bus-api-network: changing state UNSET → OPENING
systemd-networkd[2595]: Bus bus-api-network: changing state OPENING → AUTHENTICATING
systemd-networkd[2595]: timestamp of '/etc/systemd/network' changed
systemd-networkd[2595]: /etc/systemd/network/10-hoge.network:1: Invalid section header '[Network]Address=192.168.0.1'
systemd-networkd[2595]: /etc/systemd/network/10-hoge.network:1: Failed to parse file: Bad message
systemd-networkd[2595]: Assertion '*_head == _item' failed at ../../home/watanabe/git/systemd/src/network/networkd-network.c:378, function network_free(). Aborting.
valgrind[2595]: ==2595==
valgrind[2595]: ==2595== Process terminating with default action of signal 6 (SIGABRT): dumping core
valgrind[2595]: ==2595== at 0x4BCA53F: raise (in /usr/lib64/libc-2.28.so)
valgrind[2595]: ==2595== by 0x4BB4894: abort (in /usr/lib64/libc-2.28.so)
valgrind[2595]: ==2595== by 0x4955F09: log_assert_failed_realm (log.c:795)
valgrind[2595]: ==2595== by 0x417101: network_free (networkd-network.c:378)
valgrind[2595]: ==2595== by 0x415E99: network_freep (networkd-network.h:282)
valgrind[2595]: ==2595== by 0x416AB2: network_load_one (networkd-network.c:101)
valgrind[2595]: ==2595== by 0x416C39: network_load (networkd-network.c:293)
valgrind[2595]: ==2595== by 0x414031: manager_load_config (networkd-manager.c:1502)
valgrind[2595]: ==2595== by 0x40B258: run (networkd.c:82)
valgrind[2595]: ==2595== by 0x40B74A: main (networkd.c:117)
valgrind[2595]: ==2595==
valgrind[2595]: ==2595== HEAP SUMMARY:
valgrind[2595]: ==2595== in use at exit: 32,621 bytes in 201 blocks
valgrind[2595]: ==2595== total heap usage: 746 allocs, 545 frees, 241,027 bytes allocated
valgrind[2595]: ==2595==
valgrind[2595]: ==2595== LEAK SUMMARY:
valgrind[2595]: ==2595== definitely lost: 0 bytes in 0 blocks
valgrind[2595]: ==2595== indirectly lost: 0 bytes in 0 blocks
valgrind[2595]: ==2595== possibly lost: 0 bytes in 0 blocks
valgrind[2595]: ==2595== still reachable: 32,621 bytes in 201 blocks
valgrind[2595]: ==2595== suppressed: 0 bytes in 0 blocks
valgrind[2595]: ==2595== Reachable blocks (those to which a pointer was found) are not shown.
valgrind[2595]: ==2595== To see them, rerun with: --leak-check=full --show-leak-kinds=all
valgrind[2595]: ==2595==
valgrind[2595]: ==2595== For counts of detected and suppressed errors, rerun with: -v
valgrind[2595]: ==2595== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
systemd-coredump[2600]: Process 2595 (memcheck-amd64-) of user 192 dumped core.
```
Frantisek Sumsal [Fri, 18 Jan 2019 19:49:29 +0000 (20:49 +0100)]
test: mark plymouth as optional dependency
rescue.service pulls in /bin/plymouth, which doesn't exist on some
distributions (e.g. Arch Linux). Let's mark it as optional, as it's not
even required by the referencing unit and causes unwanted fails in the
integration testsuite.
The key in question is labeled as "|\" in the US version, and e.g. "<>" in
European version. In the US version there are two keys with the same label
and they are both mapped to the same keycode. Let's revert the patch, to unbreak
the non-US users.
US users should apply some local work-around, possibly simply keeping the
contents of the patch as a file in hwdb.d/.
main: when generating the resource limit to pass to children, take FD_SETSIZE into consideration
When we synthesize a "struct rlimit" structure to pass on for
RLIMIT_NOFILE to our children, let's explicitly make sure that the soft
limit is not above FD_SETSIZE, for compat reason with select().
Note this only applies when we derive the "struct rlimit" from what we
inherited. If the user configures something explicitly it always takes
precedence.
Change job mode of manager triggered restarts to JOB_REPLACE
Fixes: #11305 Fixes: #3260
Related: #11456
So, here's what happens in the described scenario in #11305. A unit goes
down, and that triggeres stop jobs for the other two units as they were
bound to it. Now, the timer for manager triggered restarts kicks in and
schedules a restart job with the JOB_FAIL job mode. This means there is
a stop job installed on those units, and now due to them being bound to
us they also get a restart job enqueued. This however is a conflicts, as
neither stop can merge into restart, nor restart into stop. However,
restart should be able to replace stop in any case. If the stop
procedure is ongoing, it can cancel the stop job, install itself, and
then after reaching dead finish and convert itself to a start job.
However, if we increase the timer, then it can always take those units
from inactive -> auto-restart.
We change the job mode to JOB_REPLACE so the restart job cancels the
stop job and installs itself.
Also, the original bug could be worked around by bumping RestartSec= to
avoid the conflicting.
This doesn't seem to be something that is going to break uses. That is
because for those who already had it working, there must have never been
conflicting jobs, as that would result in a desctructive transaction by
virtue of the job mode used.
After this change, the test case is able to work nicely without issues.
(Apparently you never configured the source tree? If you did, then the
git pre-commit hook would have been enabled which doesn't allow
commiting non-whitespace clean stuff...)
Jörg Thalheim [Mon, 14 Jan 2019 15:14:32 +0000 (15:14 +0000)]
tools/choose-default-locale.sh: set shebang to /bin/sh
The script does not use any bash features.
On NixOS we have /bin/sh and /usr/bin/env for posix compatibility
but not /bin/bash as it is stored in our nix store.
With this change one can run the `meson configure` without patching
which greatly helps, when working on upstream contributions.
tree-wide: whenever we allocate a new bus object, close it before dropping final ref
This doesn't really change much, but feels more correct to do, as it
ensures that all messages currently queued in the bus connections are
definitely unreffed and thus destryoing of the connection object will
follow immediately.
Strictly speaking this change is entirely unnecessary, since nothing
else could have acquired a ref to the connection and queued a message
in, however, now that we have the new sd_bus_close_unref() helper it
makes a lot of sense to use it here, to ensure that whatever happens
nothing that might have been queued fucks with us.
It's similar to sd_bus_flush_close_unref() but doesn't do the flushing.
This is useful since this will still discnnect the connection properly
but not synchronously wait for the peer to take our messages.
Primary usecase is within _cleanup_() expressions where synchronously
waiting on the peer is not OK.
man: use <varname> and <option> instead of <literal> in systemd.link(5)
This looks better and allows those terms to be indexed in systemd.directives.
In particular, <literal></literal> is dropped from around section names
([Match] and others) because the parens are distinctive enough on their own.
The same style is used in systemd.unit(5) and other pages that describe
sections.
link-config: add "keep" policy and use it by default
If "keep" policy is specified, and the interface has a name that is
NET_NAME_USER or NET_NAME_RENAMED, we stop processing rules. "keep" should
probably be specified either first or last depending on the preference.
This partially reimplements 55b6530baacf4658a183b15b010a8cf3483fde08, in the
sense that if the "keep" policy is not specified, and if the interface has
a NamingPolicy, it will be renamed, even if it had a name previously.
So this breaks backwards compatibility in this case, but that's more in line
with what users expect.
Ayman Bagabas [Thu, 17 Jan 2019 12:47:43 +0000 (07:47 -0500)]
hwdb: Add Huawei section and remap keys (#11406)
hwdb: Add support for 'Huawei WMI hotkeys' driver
Since 'Huawei WMI hotkeys' driver finally got merged into kernel
[commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/platform/x86/huawei-wmi.c?id=bf4fb28c6e74495de9e1e4ad359cd2272ac12c53),
this remaps 'KEY_MICMUTE' to 'F20' to make the key work and disables
brightness keys on (MACH-WX9) since it's already supported by kernel.
The error string for operations that are not supported (e.g. "shutdown" for
user-defined units) should take two arguments, where the first one is the type
of action being defined (i.e. "FailureAction" vs. "SuccessAction") and the
second is the string that was invalid.
Currently, the code prints this:
$ systemd-run --user --wait -p SuccessAction=poweroff true
Failed to start transient service unit: EmergencyAction setting invalid for manager type: SuccessAction
Change the format string to instead print:
$ systemd-run --user --wait -p SuccessAction=poweroff true
Failed to start transient service unit: SuccessAction setting invalid for manager type: poweroff
Aaron Plattner [Wed, 16 Jan 2019 18:00:21 +0000 (10:00 -0800)]
core: Fix return argument check for parse_emergency_action
This function returns 0 on success and a negative value on failure. On success,
it writes the parsed action to the address passed in its third argument.
`bus_set_transient_emergency_action` does this:
r = parse_emergency_action(s, system, &v);
if (v < 0)
// handle failure
However, `v` is not updated if the function fails, and this should be checking
`r` instead of `v`.
The result of this is that if an invalid failure (or success) action is
specified, systemd ends up creating the unit anyway and then misbehaves if it
tries to run the failure action because the action value comes from
uninitialized stack data. In my case, this resulted in a failed assertion:
Program received signal SIGABRT, Aborted.
0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
(gdb) bt
#0 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
#1 0x00007fe52cc8b672 in abort () from /snap/usr/lib/libc.so.6
#2 0x00007fe52d66f169 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD, text=0x56177ab8e000 "action < _EMERGENCY_ACTION_MAX", file=0x56177ab8dfb8 "../src/core/emergency-action.c", line=33, func=0x56177ab8e2b0 <__PRETTY_FUNCTION__.14207> "emergency_action") at ../src/basic/log.c:795
#3 0x000056177aa98cf4 in emergency_action (m=0x56177c992cb0, action=2059118610, options=(unknown: 0), reboot_arg=0x0, exit_status=1, reason=0x7ffdd2df4290 "unit run-u0.service failed") at ../src/core/emergency-action.c:33
#4 0x000056177ab2b739 in unit_notify (u=0x56177c9eb340, os=UNIT_ACTIVE, ns=UNIT_FAILED, flags=(unknown: 0)) at ../src/core/unit.c:2504
#5 0x000056177aaf62ed in service_set_state (s=0x56177c9eb340, state=SERVICE_FAILED) at ../src/core/service.c:1104
#6 0x000056177aaf8a29 in service_enter_dead (s=0x56177c9eb340, f=SERVICE_SUCCESS, allow_restart=true) at ../src/core/service.c:1712
#7 0x000056177aaf9233 in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1854
#8 0x000056177aaf921b in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGTERM, f=SERVICE_SUCCESS) at ../src/core/service.c:1852
#9 0x000056177aaf8eb3 in service_enter_stop_post (s=0x56177c9eb340, f=SERVICE_SUCCESS) at ../src/core/service.c:1788
#10 0x000056177aaf91eb in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1850
#11 0x000056177aaf91bc in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGTERM, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1848
#12 0x000056177aaf9759 in service_enter_running (s=0x56177c9eb340, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1941
#13 0x000056177ab005b7 in service_sigchld_event (u=0x56177c9eb340, pid=112, code=1, status=1) at ../src/core/service.c:3296
#14 0x000056177aad84b5 in manager_invoke_sigchld_event (m=0x56177c992cb0, u=0x56177c9eb340, si=0x7ffdd2df48f0) at ../src/core/manager.c:2444
#15 0x000056177aad88df in manager_dispatch_sigchld (source=0x56177c994710, userdata=0x56177c992cb0) at ../src/core/manager.c:2508
#16 0x00007fe52d72f807 in source_dispatch (s=0x56177c994710) at ../src/libsystemd/sd-event/sd-event.c:2846
#17 0x00007fe52d730f7d in sd_event_dispatch (e=0x56177c993530) at ../src/libsystemd/sd-event/sd-event.c:3229
#18 0x00007fe52d73142e in sd_event_run (e=0x56177c993530, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3286
#19 0x000056177aad9f71 in manager_loop (m=0x56177c992cb0) at ../src/core/manager.c:2906
#20 0x000056177aa7c876 in invoke_main_loop (m=0x56177c992cb0, ret_reexecute=0x7ffdd2df4bff, ret_retval=0x7ffdd2df4c04, ret_shutdown_verb=0x7ffdd2df4c58, ret_fds=0x7ffdd2df4c70, ret_switch_root_dir=0x7ffdd2df4c48, ret_switch_root_init=0x7ffdd2df4c50, ret_error_message=0x7ffdd2df4c60) at ../src/core/main.c:1792
#21 0x000056177aa7f251 in main (argc=2, argv=0x7ffdd2df4e78) at ../src/core/main.c:2573