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/.
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
link-config: unentangle the renaming logic and add logging
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 55b6530baacf4658a183b15b010a8cf3483fde08 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.
seccomp: drop mincore() from @system-service syscall filter group
Previously, this system call was included in @system-service since it is
a "getter" only, i.e. only queries information, and doesn't change
anything, and hence was considered not risky.
However, as it turns out, mincore() is actually security sensitive, see
the discussion here:
https://lwn.net/Articles/776034/
Hence, let's adjust the system call filter and drop mincore() from it.
This constitues a compatibility break to some level, however I presume
we can get away with this as the systemcall is pretty exotic. The fact
that it is pretty exotic is also reflected by the fact that the kernel
intends to majorly change behaviour of the system call soon (see the
linked LWN article)
This commit description says "Always rename an interface to its name specified
in config if no NamePolicy= is specified", but it does much more:
1. It completely changes the meaning of NamePolicy=kernel. Before, it meant that an interface
with type==NAMEPOLICY_KERNEL would not be renamed. After, the kernel name only works as
a fallback, if no policy matches.
2. The "if no NamePolicy= is specified" part is not true at all, the interface will be renamed
according to the specified NamePolicy=.
After 55b6530baacf, the should_rename() function is named very misleadingly: it is only used
to mean "respect kernel predictable name if no naming policy matches".
Let's revert, and start with a clean slate. This fixes #11436.
bl33pbl0p [Wed, 16 Jan 2019 00:03:22 +0000 (00:03 +0000)]
Log the job being merged
Makes it easier to understand what was merged (and easier to realize why).
Example is a start job running, and another unit triggering a verify-active job. It is not clear what job was it that from baz.service that merged into the installed job for bar.service in the debug logs. This makes it useful when debugging issues.
Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Trying to enqueue job baz.service/start/replace
Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Installed new job baz.service/start as 498
Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged into installed job bar.service/start as 497
Jan 15 11:45:58 jupiter systemd[1218]: baz.service: Enqueued job baz.service/start as 498
It becomes:
Jan 15 11:45:58 jupiter systemd[1218]: bar.service: Merged bar.service/verify-active into installed job bar.service/start as 497
So it's apparently problematic that we use STRV_MAKE() (i.e. a compound
initializer) outside of the {} block we use it in (and that includes
outside of the ({}) block, too). Hence, let's rework the macro to not
need that.
This also makes the macro shorter, which is definitely a good and more
readable. Moreover, it will now complain if the iterator is a "char*"
instead of a "const char*", which is good too.
These sysctls were added in Linux 4.19 (torvalds/linux@30aba6656f), and
we should enable them just like we enable the older hardlink/symlink
protection since v199. Implements #11414.
Daniel Axtens [Mon, 14 Jan 2019 14:15:15 +0000 (01:15 +1100)]
tests: Add test for IPv6 source routing
The test is a bit messy because it must be done on a device that
enforces a tentative state for IPv6 addresses, and it appears
that the dummy device does not. So we use a bond instead.
Daniel Axtens [Wed, 5 Dec 2018 10:49:35 +0000 (21:49 +1100)]
Install routes after addresses are ready
If an IPv6 route is added with a source address that is still
tentative, the kernel will refuse to install it.
Previously, once we sent the messages to the kernel to add the
addresses, we would immediately proceed to add the routes. The
addresses would usually still be tentative at this point, so
adding static IPv6 routes was broken - see issue #5882.
Now, only begin to configure routes once the addresses are ready,
by restructuring the state machine, and tracking when addresses are
ready, not just added.
Fixes: #5882 Signed-off-by: Daniel Axtens <dja@axtens.net>
Yu Watanabe [Sun, 13 Jan 2019 15:30:37 +0000 (00:30 +0900)]
network: make Link and NetDev always have the valid poiter to Manager
c4397d94c3d94909188d82e086ebedf5d3690569 introduces
link_detach_from_manager() and netdev_detach_from_manager(), and they
set Link::manager or NetDev::manager NULL.
But, at the time e.g. link is removed, hence link_drop() is called,
there may be still some asynchronous netlink call is waiting, and
their callbacks hit assertion.
This make {link,netdev}_detach_from_manager() just drop all references
from manager, but keep the pointer to manager.
$DBUS_SESSION_BUS_ADDRESS is again set only if the socket exists.
Quoting https://github.com/systemd/systemd/pull/11327#issuecomment-452019027:
> [setting $DBUS_SESSION_BUS_ADDRESS unconditionally] makes pam_systemd
> incompatible with installations and distributions where dbus was not
> configured with --enable-user-session, and the session dbus-daemon is started
> by autolaunching or dbus-launch (as opposed to dbus.socket). I don't think
> that's wise: using autolaunching or dbus-launch, and disabling or not
> installing dbus.socket and dbus.service on the systemd user instance, is our
> compatibility story for people who still need a D-Bus session bus per X11
> session for whatever reason.
>
> For example, Debian can currently do either way, with a dbus-user-session
> package strongly recommended but not actually mandatory. dbus-user-session
> requires libpam-systemd; if pam_systemd now requires dbus.socket (which is in
> the dbus-user-session package), that's a circular dependency, which we
> normally try hard to avoid.
For systems that use dbus.socket this doesn't matter much, because the
user session is ordered after the user managaer, which pulls in dbus.socket
very early. For example, when logging over ssh:
sshd[20796]: pam_systemd(sshd:session): pam-systemd initializing
sshd[20796]: pam_systemd(sshd:session): Asking logind to create session: uid=1001 pid=20796 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=::1
sshd[20796]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a
systemd[1]: Created slice User Slice of UID 1001.
systemd[1]: Starting User Runtime Directory /run/user/1001...
systemd-logind[1210]: New session 3796 of user guest.
systemd[1]: Started User Runtime Directory /run/user/1001.
systemd[1]: Starting User Manager for UID 1001...
systemd[20805]: pam_systemd(systemd-user:session): pam-systemd initializing
systemd[20805]: Starting D-Bus User Message Bus Socket.
...
systemd[20805]: Reached target Sockets.
systemd[20805]: Reached target Basic System.
systemd[1]: Started User Manager for UID 1001.
systemd[1]: Started Session 3796 of user guest.
sshd[20796]: pam_systemd(sshd:session): Reply from logind: id=3796 object_path=/org/freedesktop/login1/session/_33796 runtime_path=/run/user/1001 session_fd=13 seat= vtnr=0 original_uid=1001
sshd[20796]: pam_unix(sshd:session): session opened for user guest by (uid=0)
Hence, everything in the ssh session is ordered after the user instance.
And in the user instance, services should be orderd after dbus.socket using
inter-unit dependencies. dbus.socket in turns does
systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus.
So there should be no race between starting of the dbus socket and our check
if it exists.
The alternative would be to set the "DBUS_SESSION_BUS_ADDRESS=unix:path=%s/bus;autolaunch:".
AFAICT, this would work as well. But I don't see any case where it actually works
better. Since this is an area with many compatiblity concerns, let's stick to
the previous setup which seems to work well.
Mikhail Kasimov [Tue, 15 Jan 2019 12:52:34 +0000 (14:52 +0200)]
Update systemd-system.conf.xml
Updating due to phrase "Defaults to DefaultTimeoutStartSec= from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf)" from [0] https://github.com/systemd/systemd/blob/master/man/systemd.service.xml
Yu Watanabe [Tue, 8 Jan 2019 01:46:40 +0000 (10:46 +0900)]
udev: also update log level for LOG_REALM_SYSTEMD
Now, not a few udevd debug logs come from sd-device or sd-hwdb.
Only setting LOG_REALM_UDEV may not sufficient to debug.
We have already similar code in main() and udevadm.
projects / thirdparty / systemd.git / log
