| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Previously we'd honour --pid= from the main notification we send, but
not from the barrier. This is confusing at best. Let's fix that.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I guess it was only a question of time until we need to add the final
frontier of notification functions: one that combines the features of
all the others:
1. specifiying a source PID
2. taking a list of fds to send along
3. accepting a format string for the status string
Hence, let's add it.
|
| |\
| |
| | |
sd-login: add sd_uid_get_login_time interface #26574
|
| | | |
|
| |/
|
|
|
|
| |
This is a follow-up for b1712fabd1702640b04b0acdbba2d78294313a4d which
was prepped for 253, but merged into early 254 development cycle. It
thus had the symbol it adds at the wrong symver. Fix thta.
|
| | |
|
| | |
|
| |
|
|
| |
along with seqnum id
|
| |
|
|
|
|
| |
Same as the sd_pid_* counterparts, but take a pid file descriptor instead of
a pid, so that the callers can be sure that the returned values are really
about the process they asked for, and not about a recycled PID.
|
| |
|
| |
* sd-bus: convenience functions to emit a signal to a destination
|
| |
|
|
|
|
| |
In many (most?) of our event loops we want to exit once SIGTERM/SIGINT
is seen. Add a common helper for that, that does the right things in a
single call.
|
| |
|
|
|
|
|
| |
These functions provide a high-level interface for enumerating
child devices.
Suggested at https://github.com/systemd/systemd/pull/24731#discussion_r973987065.
|
| |
|
|
|
|
|
| |
This effectively reverts 84e1001541151da71bae2137e2a1c254b5a3b89f.
The sd-netlink library has several issues, and we should not export it
without solving them. See issues #24258 and #24124.
|
| |
|
|
| |
It was somewhat similar to sd_netlink_open_fd(), and unused.
|
| |
|
|
| |
sd_netlink_message_set_request_dump
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We have RxBufferSize= and TxBufferSize= in .link files. Let's use the same
abbreviation here. OTOH, "inc" could be short for "increment" or "increase",
let's avoid that.
|
| |
|
|
|
| |
The same story as before: it's a useful helper, other uses of the library
are likely to find it useful.
|
| |
|
|
|
|
|
|
| |
We find this function useful in our code, so no reason not to export it.
I changed the order of last two words in the name to match the arguments.
(With "equal_string" I expected sd_id128_t first, string second, but in
actual use, the second argument is usually a long constant so it's nice
to keep this order of arguments.)
|
| |
|
|
|
|
| |
The usual: if we find that function useful, other users of the library
will too. In particular, the v-variants are necessary to build pass-thru
wrappers.
|
| |
|
|
|
|
|
|
|
|
|
| |
It was added originally in 65f568bbeb9b8c70200e44c19a797df3a0bfd485. The API is
has stabilized pretty much, and generally follows the usual style for
libsystemd. We've held it as a public-but-private library for almost 10 years,
let's export it.
sd_netlink_sendv() and sd_nfnl_nft_*() are excluded.
libsystemd.so seems to grow by 12k.
|
| |
|
|
|
|
|
|
|
|
| |
The existing sd_hwdb_new function always initializes the hwdb from the
first successful hwdb.bin it finds from hwdb_bin_paths. This means there
is currently no way to initialize a hwdb from an explicit path, which
would be useful for systemd-hwdb query.
Add sd_hwdb_new_from_path to allow a sd_hwdb to be initialized from a
custom path outside of hwdb_bin_paths.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We usually open() device node obtained by sd_device_get_devname().
However, the device node corresponds to the sd-device object may be
already removed, and another device node with the same path may be
created, hence an unexpected device may be opened.
The sd_device_open() opens device node, and checks the devnum and
diskseq of opened devnum, to avoid the above possibility.
Prompted by https://github.com/systemd/systemd/issues/22906#issuecomment-1082736443.
|
| |
|
|
| |
and sd_device_new_from_path() which takes devname or syspath.
|
| |
|
|
|
|
|
|
|
| |
We expose various other forms of UUID helpers already, i.e.
SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse
UUIDs, hence add a high-level helper for formatting UUIDs too.
This doesn't add any new code, it just moves some helpers
id128-util.[ch] → sd-id128.[ch], to make them public.
|
| | |
|
| |
|
|
|
| |
sd_event_add_inotify_fd() is like sd_event_add_inotify(), but takes an
fd to an inode instead of a path, and is hence a ton nicer.
|
| |
|
|
|
|
|
| |
DISKSEQ is a monotonic per-use unique sequence number, incremented
on each block device create/attach. For example, the same loop device
will have different diskseq each time an object is attached to it.
Add sd/udev helpers to parse/expose it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since kernel 4.13 the kerne allows passing a UUID to generated uevents.
Optionally do so via a new sd_device_trigger_with_uuid() call, and add
sd_device_get_trigger_uuid() as helper to retrieve the UUID from a
uevent we receive.
This is useful for tracking uevents through the udev system, and waiting
for specific triggers.
(Note that the 4.13 patch allows passing arbitrary meta-info into the
uevent as well. This does not add an API for that, because I am not
convinced it makes sense — as it conflicts with our general rule that
events are "stateless" if you so will — and it complicates the interface
quite a bit).
This replaces #13881 in a way, which added a similar infra, but which
stalled, and whose synchronous settling APIs are somewhat problematic
and probably not material to merge.
|
| |
|
|
|
|
|
|
|
| |
We already store a CLOCK_MONOTONIC timestamp for each device appearance,
let' make this queriable.
This is useful to determine whether a udev device database entry is from
a current appearance of the device or a previous one, by comparing it
with appropriately taken timestamps.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
there's no point in having two arguments, if one does as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sd_device_new_from_stat_rdev()
To make sd-device properly usable for all programs we need to provide an
API for the "action" field of an event, it's one of the most relevant
ones, and it was so far missing.
This also adds sd_device_get_seqnum(), which isn't that interesting,
except for generating pretty debug output, which we use it ourselves
for.
This also makes device_new_from_stat_rdev() public, as it is truly
useful, as we can see in our own uses of it, and I think is fairly
generic to show up in the public APIs.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
While sd-bus already provides sd_bus_call() for calling a method
from a complete bus message object, We don't have an equivalent
function for replying from a method with a complete bus message
object.
Currently, we use sd_bus_send(call->bus, m, NULL) instead. Let's
add a shorthand for this pattern and name it sd_bus_reply().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
container
This is unfortunately harder to implement than it sounds. The user's bus
is bound a to the user's lifecycle after all (i.e. only exists as long
as the user has at least one PAM session), and the path dynamically (at
least theoretically, in practice it's going to be the same always)
generated via $XDG_RUNTIME_DIR in /run/.
To fix this properly, we'll thus go through PAM before connecting to a
user bus. Which is hard since we cannot just link against libpam in the
container, since the container might have been compiled entirely
differently. So our way out is to use systemd-run from outside, which
invokes a transient unit that does PAM from outside, doing so via D-Bus.
Inside the transient unit we then invoke systemd-stdio-bridge which
forwards D-Bus from the user bus to us. The systemd-stdio-bridge makes
up the PAM session and thus we can sure tht the bus exists at least as
long as the bus connection is kept.
Or so say this differently: if you use "systemctl -M lennart@foobar"
now, the bus connection works like this:
1. sd-bus on the host forks off:
systemd-run -M foobar -PGq --wait -pUser=lennart -pPAMName=login systemd-stdio-bridge
2. systemd-run gets a connection to the "foobar" container's
system bus, and invokes the "systemd-stdio-bridge" binary as
transient service inside a PAM session for the user "lennart"
3. The systemd-stdio-bridge then proxies our D-Bus traffic to
the user bus.
sd-bus (on host) → systemd-run (on host) → systemd-stdio-bridge (in container)
Complicated? Well, to some point yes, but otoh it's actually nice in
various other ways, primarily as it makes the -H and -M codepaths more
alike. In the -H case (i.e. connect to remote host via SSH) a very
similar three steps are used. The only difference is that instead of
"systemd-run" the "ssh" binary is used to invoke the stdio bridge in a
PAM session of some other system. Thus we get similar implementation and
isolation for similar operations.
Fixes: #14580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's a concept of "rate limiting" to event sources: if specific event
sources fire too often in some time interval temporarily take them
offline, and take them back online once the interval passed.
This is a simple scheme of avoiding starvation of event sources if some
event source fires too often.
This introduces the new conceptual states of "offline" and "online" for
event sources: an event source is "online" only when enabled *and* not
ratelimited, and offline in all other cases. An event source that is
online hence has its fds registered in the epoll, its signals in the
signalfd and so on.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if an event source callback returns an error, we'll disable
the event source and continue. This adds a per-event source flag that if
turned on goes further: the event loop is also exited, propagating the
error code.
This is inspired by some patterns repeatedly seen in #15206.
The idea is that event sources that server the "primary" function of a
program are marked like this, so that if they fail the failure is
instantly propagated and terminates the program.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tries to address the "bind"/"unbind" uevent kernel API breakage, by
changing the semantics of device tags.
Previously, tags would be applied on uevents (and the database entries
they result in) only depending on the immediate context. This means that
if one uevent causes the tag to be set and the next to be unset, this
would immediately effect what apps would see and the database entries
would contain each time. This is problematic however, as tags are a
filtering concept, and if tags vanish then clients won't hence notice
when a device stops being relevant to them since not only the tags
disappear but immediately also the uevents for it are filtered including
the one necessary for the app to notice that the device lost its tag and
hence relevance.
With this change tags become "sticky". If a tag is applied is once
applied to a device it will stay in place forever, until the device is
removed. Tags can never be removed again. This means that an app
watching a specific set of devices by filtering for a tag is guaranteed
to not only see the events where the tag is set but also all follow-up
events where the tags might be removed again.
This change of behaviour is unfortunate, but is required due to the
kernel introducing new "bind" and "unbind" uevents that generally have
the effect that tags and properties disappear and apps hence don't
notice when a device looses relevance to it. "bind"/"unbind" events were
introduced in kernel 4.12, and are now used in more and more subsystems.
The introduction broke userspace widely, and this commit is an attempt
to provide a way for apps to deal with it.
While tags are now "sticky" a new automatic device property
CURRENT_TAGS is introduced (matching the existing TAGS property) that
always reflects the precise set of tags applied on the most recent
events. Thus, when subscribing to devices through tags, all devices that
ever had the tag put on them will be be seen, and by CURRENT_TAGS it may
be checked whether the device right at the moment matches the tag
requirements.
See: #7587 #7018 #8221
|
| |
|
|
|
|
| |
The next release is 247, not 248.
A follow-up for 2b07ec316a0e25a3e10c270c7f6baee9e0187bf8
|
| | |
|
