Jörg Thalheim [Mon, 18 Dec 2017 14:17:06 +0000 (15:17 +0100)]
sd-netlink: add generic netlink support
This also adds the ability to incorporate arrays into netlink messages
and to determine when a netlink message is too big, used by some generic
netlink protocols.
Susant Sahani [Tue, 9 Jan 2018 08:13:06 +0000 (13:43 +0530)]
networkd: call link_set_routing_policy_rule before setting routes (#7815)
commit 7715629 (networkd: Fix race condition in [RoutingPolicyRule] handling (#7615)).
Does not fix race. Still there is a race in case of bride because the
bride goes down and up .
calling route_configure then link_set_routing_policy_rule and the
link_check_ready makes a race between routing_policy_rule_messages and route_messages.
While bride comes up and we call the call again route_configure if finds
it self in the callback function LINK_STATE_CONFIGURED networkd dies.
Let's handle first routing policy rules then route_configure. This fixes
the crash.
Closes #7797
Thomas Huth [Mon, 8 Jan 2018 09:49:15 +0000 (10:49 +0100)]
rules: Mark the kvm device as static_node (for s390x and ppc64) (#7795)
On s390x and ppc64, the permissions of the /dev/kvm device are currently
not right as long as the kvm kernel module has not been loaded yet. The
kernel module is using MODULE_ALIAS("devname:kvm") there, so the module
will be loaded on the first access to /dev/kvm. In that case, udev needs
to apply the permission to the static node already (which was created via
devtmpfs), i.e. we have to specify the option "static_node=kvm" in the
udev rule.
Note that on x86, the kvm kernel modules are loaded early instead (via the
MODULE_DEVICE_TABLE(x86cpu, ...) feature checking), so that the right module
is loaded for the Intel or AMD hypervisor extensions right from the start.
Thus the "static_node=kvm" is not required on x86 - but it also should not
hurt here (and using it here even might be more future proof in case the
module loading is also done delayed there one day), so we just add the new
option to the rule here unconditionally.
Yu Watanabe [Sun, 7 Jan 2018 16:36:08 +0000 (01:36 +0900)]
sd-device: support the case that /sys is a symlink
When /sys is a symlink to the sysfs mountpoint, e.g. /path/to/sysfs.
Then, device->syspath was set to like /path/to/sysfs/devices/foo/baz.
This converts the path to /sys/devices/foo/baz.
rkolchmeyer [Fri, 5 Jan 2018 18:28:23 +0000 (10:28 -0800)]
core: Fix edge case when processing /proc/self/mountinfo (#7811)
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
When loading .netdev files we parse them twice: first we do one parsing
iteration to figure out their "kind", and then we do it again to parse
out the kind's parameters. The first iteration is run with a "short"
NetDev structure, that only covers the generic NetDev properties. Which
should be enough, as we don't parse the per-kind properties. However,
before this patch we'd still try to destruct the per-kind properties
which resulted in memory corruption. With this change we distuingish the
two iterations by the state field, so that the destruction only happens
when the state signals we are running with a full NetDev structure.
Since this is not obvious, let's add a lot of comments.
sd-bus: remove 'hint_sync_call' parameter from various function calls
This is unused since kdbus is gone, hence remove this too. This permits
us to get rid of sd_bus_send_internal() and just implement sd_bus_send()
directly.
pid1: set org.freedesktop.systemd1 as sender service name for direct connections
This way, clients can install the very same match on direct and broker
connections as in both cases the messages will originate from the o.f.s1
service.
sd-bus: add API to optionally set a sender field on all outgoing messages
This is useful on direct connections to generate messages with valid
sender fields.
This is particularly useful for services that are accessible both
through direct connections and the broker, as it allows clients to
install matches on the sender service name, and they work the same in
both cases.
sd-bus: accept NULL callbacks in sd_bus_call_async()
This way sd_bus_call_method_async() (which is just a wrapper around
sd_bus_call_async()) can be used to put method calls together that
expect no reply.
networkd,resolved: make use of watch_bind feature to connect to the bus
The changes both networkd and resolved to make use of the watch_bind
feature of sd-bus to connect to the system bus. This way, both daemons
can be started during early boot, and automatically and instantly
connect to the system bus as it becomes available.
This replaces prior code that used a time-based retry logic to connect
to the bus.
With this new API sd-bus can synthesize a local "Connected" signal when
the connection is fully established. It mirrors the local "Disconnected"
signal that is already generated when the connection is terminated. This
is useful to be notified when connection setup is done, in order to
start method calls then, in particular when using "slow" connection
methods (for example slow TCP, or most importantly the "watch_bind"
inotify logic).
Note that one could also use hook into the initial NameAcquired signal
received from the bus broker, but that scheme works only if we actually
connect to a bus. The benefit of "Connected" OTOH is that it works with
any kind of connection.
Ideally, we'd just generate this message unconditionally, but in order
not to break clients that do not expect this message it is opt-in.
This new call is much light sd_bus_is_open(), but returns true only if
the connection is fully set up, i.e. after we finished with the
authentication and Hello() phase. This API is useful for clients in
particular when using the "watch_bind" feature, as that way it can be
determined in advance whether it makes sense to sync on some operation.
sd-bus: drop references to legacy /var/run D-Bus socket
Let's directly reference /run instead, so that we can work without /var
being around, or with /var/run being incorrectly set up.
Note that we keep the old socket path in place when referencing the
system bus of containers, as they might be foreign operating systems,
that still don't have adopted /run, and where it makes sense to use the
standardized name instead. On local systems, we insist on /run being set
up properly however, hence this limitation does not apply.
Also, get rid of the UNIX_SYSTEM_BUS_ADDRESS and
UNIX_USER_BUS_ADDRESS_FMT defines. They had a purpose when we still did
kdbus, as we then had to support two different backends. But since
that's gone, we don't need this indirection anymore, hence settle on a
one define only.
Let's remove a number of synchronization points from our service
startups: let's drop synchronous match installation, and let's opt for
asynchronous instead.
Also, let's use sd_bus_match_signal() instead of sd_bus_add_match()
where we can.
sd-bus: add new API sd_bus_match_signal() + sd_bus_match_signal_asnyc()
These are convenience helpers that hide the match string logic (which we
probably should never have exposed), and instead just takes regular C
arguments.
sd-bus: add asynchronous version of sd_bus_match()
We usually enqueue a number of these calls on each service
initialization. Let's do this asynchronously, and thus remove
synchronization points. This improves both performance behaviour and
reduces the chances to deadlock.
sd-bus: when removing a server-side match, do so in "fire and forget" fashion
We currently wait for the RemoveMatch() reply, but then ignore what it
actually says. Let's optimize this a bit, and not even ask for an answer
back: just enqueue the RemoveMatch() operation, and do not request not
wait for any answer.
sd-bus: add APIs to request/release names asynchronously
They do the same thing as their synchronous counterparts, but only
enqueue the operation, thus removing synchronization points during
service initialization.
If the callback function is passed as NULL we'll fallback to generic
implementations of the reply handlers, that terminate the connection if
the requested name cannot be acquired, under the assumption that not
being able to acquire the name is a technical problem.
When kdbus was still around we always had two implementations of the
various control calls: one for dbus1 and one for kdbus. Let'sget rid of
this, simplify things, and just merge the wrappers that used to
multiplex this with the implementations.
No change in behaviour, just some merging of functions
sd-bus: start reply callback timeouts only when the connection is established
Currently, reply callback timeouts are started the instant the method
calls are enqueued, which can be very early on. For example, the Hello()
method call is enqueued right when sd_bus_start() is called, i.e. before
the socket connection and everything is established.
With this change we instead start the method timeout the moment we
actually leave the authentication phase of the connection. This way, the
timeout the kernel applies on socket connecting, and we apply on the
authentication phase no longer runs in parallel to the Hello() method
call, but all three run serially one after the other, which is
definitely a cleaner approach.
Moreover, this makes the "watch bind" feature a lot more useful, as it
allows enqueuing method calls while we are still waiting for inotify
events, without them timeouting until the connection is actually
established, i.e. when the method call actually has a chance of being
actually run.
This is a change of behaviour of course, but I think the new behaviour
is much better than the old one, since we don't race timeouts against
each other anymore...
sd-bus: optionally, use inotify to wait for bus sockets to appear
This adds a "watch-bind" feature to sd-bus connections. If set and the
AF_UNIX socket we are connecting to doesn't exist yet, we'll establish
an inotify watch instead, and wait for the socket to appear. In other
words, a missing AF_UNIX just makes connecting slower.
This is useful for daemons such as networkd or resolved that shall be
able to run during early-boot, before dbus-daemon is up, and want to
connect to dbus-daemon as soon as it becomes ready.
bus: touch() the AF_UNIX sockets we listen() on after the fact
We'd like to use inotify to get notified when AF_UNIX sockets become
connectable. That happens at the moment of listen(), but this is doesn't
necessarily create in a watchable inotify event. Hence, let's synthesize
one whenever we generically create a socket, or when we know we created
it for a D-Bus server.
Ideally we wouldn't have to do this, and the kernel would generate an
event anyway for this. Doing this explicitly isn't too bad however, as
the event is still nicely associated with the AF_UNIX socket node, and
we generate all D-Bus sockets in our code hence it's safe.
socket-util: explicitly ensure there's one trailing NUL byte on AF_UNIX socket addresses
AF_UNIX socket addresses aren't necessarily NUL terminated, however
they are usually used as strings which are assumed to be NUL terminated.
Let's hence add an extra byte to the end of the sockaddr_un structure,
that contains this NUL byte, simply for safety reasons.
Note that actually this patch changes exactly nothing IRL, as the other
sockaddr structures already are large enough to accomodate for an extra
NUL byte. The size of the union hence doesn't change at all by doing
this. The entire value of this patch is hence in the philosophical
feeling of safety, and by making something explicit that before was
implicit.
This changes two things when binding to AF_UNIX file system sockets:
1. When wethe socket already exists in the fs, and unlink() on it fails,
don't bother to bind() a second time: since nothing changed it won't
work either.
2. Also use SELinux-aware bind() for the second attempt.
fs-util: rework touch_file() so that it can touch socket file nodes
Let's rework touch_file() so that it works correctly on sockets, fifos,
and device nodes: let's open an O_PATH file descriptor first and operate
based on that, if we can. This is usually the better option as it this
means we can open AF_UNIX nodes in the file system, and update their
timestamps and ownership correctly. It also means we can correctly touch
symlinks and block/character devices without triggering their drivers.
Moreover, by operating on an O_PATH fd we can make sure that we
operate on the same inode the whole time, and it can't be swapped out in
the middle.
While we are at it, rework the call so that we try to adjust as much as
we can before returning on error. This is a good idea as we call the
function quite often without checking its result, and hence it's best to
leave the files around in the most "correct" fashion possible.
sd-bus: when attached to an sd-event loop, disconnect on processing errors
If we can't process the bus for some reason we shouldn't just disable
the event source, but log something and give up on the connection. Hence
do that, and disconnect.
sd-bus: propagate handling errors for Hello method reply directly
Currently, when sd-bus is used to issue a method call, and we get a
reply and the specified reply handler fails, we log this locally at
debug priority and proceed. The idea is that a bad server-side reply
should not be fatal for the program, except when the developer
explicitly terminates the event loop.
The reply to the initial Hello() method call we issue when joining a bus
should not be handled like that however. Instead, propagate the error
immediately, as anything that is wrong with the Hello() reply should be
considered a fatal connection problem.
systemd-udevd: fix speed/duplex processing with valid .link files (#7808)
Including BitsPerSecond or Duplex values in .link files did not work when
set_slinksettings was called because the routine was not copying the base
parameters to the structure given to ioctl. As a result, EINVAL was always
reported, and no change occurred on the Ethernet device.
Alexis Deruelle [Fri, 5 Jan 2018 00:17:17 +0000 (01:17 +0100)]
Touchpad range : add another Macbook4,1 variant (#7749)
#Add "Early 2008 Core 2 Duo/Penryn" Macbook4,1 match string to the existing touchpad range definition
##Symptoms
* Jerky/Jumpy cursor motion using touchpad
* "Axis value outside expected range" message in Xorg.0.log
##Fix
I followed the instructions described here :https://wayland.freedesktop.org/libinput/doc/latest/absolute_coordinate_ranges.html and came up with the following :
If read_line() returns ENOBFUS this means the line was overly long. When
we use this for checking whether an executable is a script, then this
shouldn't be propagated as-is, but simply as "this is not a script".
fileio: tweak write_string_stream_ts() to write out trailing \n in one go even if buffering is off
This tweaks write_string_stream_ts() in one minor way: when stdio
buffering has been turned off, let's append the newline we shall append
to the buffer we write ourselves so that the kernel only gets one
syscall for the result. When buffering is enabled stdio will take care
of that anyway.
journald: introduce new uid_for_system_journal() helper
We use the same check at two places, let's add a tiny helper function
for it, since it's not entirely trivialy, and we changes this before
multiple times, and it's a good thing if we can change it at one place
only instead of multiple.
Let's call getsockopt() in a loop, so that we can deal correctly with
the label changing while we are trying to read it.
(also, while we are at it, let's make sure that there's always one
trailing NUL byte at the end of the buffer, after all SO_PEERSEC has
zero documentation, and multiple implementing backends, hence let's
better be safe than sorry)
tree-wide: use {pid,uid,gid}_is_valid() where appropriate
Also, drop UID/GID validity checks from getpeercred() as the kernel will
never pass us invalid UID/GID on userns, but the overflow UID/GID
instead. Add a comment about this.
tree-wide: in all threads we fork off in library code, block all signals
This ensures that in all threads we fork off in the background in our
code we mask out all signals, so that our thread won't end up getting
signals delivered the main process should be getting.
We always set the signal mask before forking off the thread, so that the
thread has the right mask set from its earliest existance on.
pager,agent: insist that we are called from the main thread
We maintain static process-wide variables in these subsystems without
locking, hence let's refuse operation unless we are called from the main
thread (which we do anyway) just as a safety precaution.
tree-wide: make use of wait_for_terminate_and_check() at various places
Using wait_for_terminate_and_check() instead of wait_for_terminate()
let's us simplify, shorten and unify the return value checking and
logging of waitid(). Hence, let's use it all over the place.
process-spec: add another flag FORK_WAIT to safe_fork()
This new flag will cause safe_fork() to wait for the forked off child
before returning. This allows us to unify a number of cases where we
immediately wait on the forked off child, witout running any code in the
parent after the fork, and without direct interest in the precise exit
status of the process, except recgonizing EXIT_SUCCESS vs everything
else.
process-util: rework wait_for_terminate_and_warn() to take a flags parameter
This renames wait_for_terminate_and_warn() to
wait_for_terminate_and_check(), and adds a flags parameter, that
controls how much to log: there's one flag that means we log about
abnormal stuff, and another one that controls whether we log about
non-zero exit codes. Finally, there's a shortcut flag value for logging
in both cases, as that's what we usually use.
All callers are accordingly updated. At three occasions duplicate logging
is removed, i.e. where the old function was called but logged in the
caller, too.
Mike Gilbert [Thu, 4 Jan 2018 12:14:20 +0000 (07:14 -0500)]
meson: don't search PATH for telinit (#7770)
On a typical system running systemd, the telinit in PATH is very likely to be a symlink
to systemctl. Setting TELINIT to this may result in an infinite recursion if telinit is called
and sd_booted() == 0. This may commonly occur in a chroot environment.
projects / thirdparty / systemd.git / log
