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.
```
Gentoo's Portage package manager uses a PID namespace for process
isolation and cleanup. In this namespace, PID 1 has UID=250 (portage).
Bug: https://bugs.gentoo.org/674458
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.
This reverts commit e05c8b4462.
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/.
Before adding this, I got errors about the library being missing such
as:
journalctl: error while loading shared libraries: libqrencode.so.4: cannot open shared object file: No such file or directory
Fixes#7367.
Fixes: #11305Fixes: #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.
Instead of having just a single INITRD field, add support for all
additional parameters being INITRD fields in order.
Signed-off-by: Mike Auty <mike.auty@gmail.com>
@bl33pbl0p, please fix your editor
(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...)
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.
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.
Fixes#10659.
This changes the behaviour of parsing environment files to more closely
follow POSIX shell standards.
This has the effect that these variables defined in a file:
VAR1='\value'
VAR2="\value"
Are now interpreted as `\value` instead of interpreting the `\`
character and interpreting them as `value`.
For more information about the behaviour followed, see:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
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.
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 55b6530baa, 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.
Closes#9006.
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
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
Fix this by checking the correct variable.
What policy we dicide to use it rather important, but this bit of information
wasn't logged. Let's always do that.
The code was also written in a confusing way, which probably contributed to the
unintended effects of 55b6530baa and other commits.
We would loop over all policies, and note if "kernel" was specified, and then
possibly unset the result at the end. Let's immediately log the result and cut
to the end if we can figure out the answer.
No functional change intended, except for the new log lines.
Using goto is not very elegant, but we can't use break because of the switch,
and there are multiple conditions to break the loop, so using goto is cleanest.
AFAICT, it was never hooked up to meson, so it'd only work if somebody manually
defined the flag. I think it's preferable to drop the ifdef: it removes only a
single access call to a fixed location, which is realy cheap. If poeple don't
want to make use of this, they should just not create the file. Making this
both compile-time optional and opt-in in the filesystem is unnecessary.
