| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=89226
|
| |
|
|
|
|
| |
none/both/v4/v6 are deprecated in favour of no/yes/ipv4/ipv6.
https://bugs.freedesktop.org/show_bug.cgi?id=89221
|
| |
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=89559
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
journal-remote buffers input, and then parses it handling one journal entry at a time.
It was possible for useful data to be left in the buffer after some entries were
processesed. But all data would be already read from the fd, so there would be
no reason for the event loop to call the handler again. After some new data came in,
the handler would be called again, and would then process the "old" data in the buffer.
Fix this by enabling a handler wherever we process input data and do not exhaust data
from the input buffer (i.e. when EAGAIN was not encountered). The handler runs until
we encounter EAGAIN.
Looping over the input data is done in this roundabout way to allow the event loop
to dispatch other events in the meanwhile. If the loop was inside the handler, a
source which produced data fast enough could completely monopolize the process.
https://bugs.freedesktop.org/show_bug.cgi?id=89516
|
| |
|
|
| |
This matches similar code elsewhere.
|
| |
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=89486
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Notifications are of informal nature and no reply is expected, therefore the
sequence number is typically set to 0."[1]
If networkd is started soon after recent netlink activity, then there
will be messages with sequence number 0 in the buffer.
The first thing networkd does is to request a dump of all the links. If
it uses sequence number 0 for this, then it may confuse the dump request's
response with that of a notification.
This will result in it failing to properly enumerate all the links,
but more importantly, when it comes to enumerate all the addresses, it
will still have the link dump in progress, so the address enumeration
will fail with -EBUSY.
[1]: http://www.infradead.org/~tgr/libnl/doc/core.html#core_msg_types
[tomegun: sequence -> serial]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newly added kernel drivers repeatedly pass our blacklist and
cause trouble for the devices, because they do not expect to
be examined by udev's default rules which include blkid.
This turns the blacklist into a whitelist. Device type which
need support for additional symlinks need to be added to the
whitelist now.
Note, that the by-id, by-path symlinks are only intended for
hotpluggable devices. There is no reason for exotic, or for
statically configured devices to provide them.
|
| | |
|
| |
|
|
|
| |
Explicitly put the "multiple EnvironmentFile=" description into its own
paragraph to make it much easier to find.
|
| | |
|
| |
|
|
|
|
| |
The information in the db is stale, so it does not make sense to
expose it any longer. Also, don't drop the kernel event, but simply
pass it on to userspace without ammending it.
|
| |
|
|
| |
This will allow us to clean up the device when we are notified about the worker being killed.
|
| |
|
|
| |
This allows us to move the db reading from udevd to libudev.
|
| |
|
|
| |
Return -errno rather than -1 in case sendmsg() fails.
|
| |
|
|
|
|
|
|
|
| |
We were explicitly eagerly loading the db, then deletenig the backing file and then processing the
rules/symlinks. Instead we delete the backnig db file as the last step and let the db loading be
lazy as everywhere else.
This may save us a bit of work in casese where the db is not needed, but more importantly it hides
some implementation details of libudev-device form udevd.
|
| |
|
|
| |
To copy properties from one device to another. Drop the equivalent functionality from udevd.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
systemd-cgtop --dept=1 -b -n 10 -d 0.1 | cat
Assertion 'new_length >= 3' failed at src/shared/util.c:3 \
595, function ellipsize_mem(). Aborting.
Aborted (core dumped)
(David: add comment)
|
| |
|
|
|
|
| |
On kdbus, we get cgroups-agent messages via the system bus, not the
private systemd socket. Therefore, we must install the match properly or
we will never receive cgroup notifications.
|
| |
|
|
|
|
| |
Forwarding messages that are not rewinded will drop data. Fix this for
cgroups-agent messages that we might remarshal before forwarding to the
system bus.
|
| |
|
|
|
|
| |
If we receive an sd_bus_message from the kernel, m->kdbus will contain
additional items that cannot be used when sending a message. Therefore,
always remarshal the message if it is used again.
|
| |
|
|
|
| |
This assignment is already done in the parent context, no need to do it
again.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the local peer does not dispatch its incoming queue, the bus-proxy will
slowly fill its outgoing queue. Once its full, it will continously
complain that it cannot forward its messages.
As it turns out, pulseaudio does have an idle background dbus connection
that is not integrated into any mainloop (and given that gdbus and
libdbus1 both support background shared connections, PA is probably not
the only example), therefore, the bus-proxy will loudly complain if it
cannot forward NameOwnerChanged events once the queue is full.
This commit makes the proxy track queue-state and complain only once the
queue runs full, not if it is already full.
A PA bug-report (and patch) has been filed, and other applications should
be fixed similarly. Hence, lets keep the error message, instead of
dropping it. It's unused resources we really want to get rid of, so
silencing the message does not really help (which is actually what
dbus-daemon does).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new SYSVIEW_EVENT_SETTLE notification that is sent after
initial scanning via sysview is done. This is very handy to let the
application raise warnings in case requested resources are not found
during startup.
The SETTLE event is sent after systemd-logind and udev enumerations are
done. This event does in no way guarantee that a given resource is
available. All it does is notify the application that scanning is done!
You must not react to SETTLE if you don't have external synchronization
with the resource you're waiting for.
The main use-case for SETTLE is to run applications _inside_ of logind
sessions and startup sysview. You really want to make sure that the own
session you're running in was found during enumeration. If not, something
is seriously wrong.
|
| |
|
|
|
|
| |
The error-code propagated via sysview is always negative. Avoid
multiplying by -1 before returning it. Otherwise, we will return >0
instead of <0, which will not be detected as error by sysview-core.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
renameat2() exists since Linux 3.15 but btrfs support for the flag
RENAME_NOREPLACE was added later.
This patch implements a fallback when renameat2() returns EINVAL.
EINVAL is the error returned when the filesystem does not support one of
the flags.
|
| |
|
|
|
|
|
|
|
| |
path_is_mount_point() compares the mount_id of a directory and the
mount_id of the parent directory. When following symlinks, the function
to get the parent directory does not take the symlink into account.
/bin -> /usr/bin with /usr being a mountpoint:
mount_id of /bin with AT_SYMLINK_FOLLOW != mount_id of /
|
| | |
|
| |
|
|
|
|
|
|
|
| |
GetConnectionCredentials method was added to dbus-1 specification
more than one year ago. This method should return "[...] as many
credentials as possible for the process connected to the server",
but at this moment only "UnixUserID", "LinuxSecurityLabel" and
"ProcessID" are defined by the specification. We should add support
for next credentials after extending dbus-1 spec.
|
| | |
|
| | |
|
| | |
|
| | |
|
