| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
A macro is needed because otherwise we couldn't ensure type safety.
Some simple tests are included.
No functional change intended.
|
| | |
|
| | |
|
| |
|
|
|
| |
The intent is for the call to succeed only when privileged, so make
that clear.
|
| |
|
|
|
|
|
| |
sd_bus_wait(): ETIMEDOUT
Thankfully this is an internal API still, so we can mkae changes like
this.
|
| |
|
|
|
|
|
| |
Let's explicitly tell PID 1 that we don't need an fd anymore, instead of
relying exclusively on POLLERR/POLLHUP for it to be removed.
Fixes: #6908
|
| |
|
|
| |
Fixes: #7466
|
| |
|
|
| |
CID #1383004
|
| | |
|
| |
|
|
|
|
| |
Now that we don't kill control processes anymore, let's at least warn
about any processes left-over in the unit cgroup at the moment of
starting the unit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the bpf cgroup realization state was implicitly set
to "NO", meaning that the bpf configuration was realized but was turned
off. That means invalidation requests for the bpf stuff (which we issue
in blanket fashion when doing a daemon reload) would actually later
result in a us re-realizing the unit, under the assumption it was
already realized once, even though in reality it never was realized
before.
This had the effect that after each daemon-reload we'd end up realizing
*all* defined units, even the unloaded ones, populating cgroupfs with
lots of unneeded empty cgroups.
With this fix we properly set the realiazation state to "INVALIDATED",
i.e. indicating the bpf stuff was never set up for the unit, and hence
when we try to invalidate it later we won't do anything.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shall actually realize
We add units to the cgroup realization queue when propagating realizing
requests to sibling units, and when invalidating cgroup settings because
some cgroup setting changed. In the time between where we add the unit
to the queue until the cgroup is actually dispatched the unit's state
might have changed however, so that the unit doesn't actually need to be
realized anymore, for example because the unit went down. To handle
that, check the unit state again, if realization makes sense.
Redundant realization is usually not a problem, except when the unit is
not actually running, hence check exactly for that.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That is version 7 or greater
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
Fix regression of https://github.com/elogind/elogind/pull/7389
82a27ba8217d09e4fef4c9550f8b733d174c5705
on older gccs
bumping to re-run CI
upstream FAIL timed out
boot-smoke FAIL non-zero exit status 1
|
| | |
|
| |
|
|
|
| |
Now that d3070fbdf6077d7d has been merged, these errors are not as
critical as they used to be.
|
| | |
|
| |
|
|
|
|
|
|
| |
Similar to the virtual ethernet driver veth, vxcan implements a
local CAN traffic tunnel between two virtual CAN network devices.
When creating a vxcan, two vxcan devices are created as pair
When one end receives the packet it appears on its pair and vice
versa. The vxcan can be used for cross namespace communication.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make sure to add the delegation mask to the mask of controllers we have
to enable on our own unit. Do not claim it was a members mask, as such
a logic would mean we'd collide with cgroupv2's "no processes on inner
nodes policy".
This change does the right thing: it means any controller enabled
through Controllers= will be made available to subcrgoups of our unit,
but the unit itself has to still enable it through
cgroup.subtree_control (which it can since that file is delegated too)
to be inherited further down.
Or to say this differently: we only should manipulate
cgroup.subtree_control ourselves for inner nodes (i.e. slices), and
for leaves we need to provide a way to enable controllers in the slices
above, but stay away from the cgroup's own cgroup.subtree_control —
which is what this patch ensures.
Fixes: #7355
|
| |
|
|
|
|
| |
When a process becomes a zombie its cgroup might be deleted. Let's add
some minimal code to detect cases like this, so that we can still
attribute this back to the original cgroup.
|
| |
|
|
|
|
|
|
| |
Distcc removes comments, making the comment silencing
not work.
I know there was a decision against a macro in commit
ec251fe7d5bc24b5d38b0853bc5969f3a0ba06e2
|
| | |
|
| |
|
|
|
| |
Let's not mix function calls and variable declarations, as well as
assignments and comparison in one expression.
|
| |
|
|
|
| |
We do a logic like that at various other places, let's do it here too,
to make this as little surprising as possible.
|
| |
|
|
|
|
|
|
|
| |
If the string length is specified as (size_t) -1, let's use that as
indicator for determining the length on our own. This makes it
slightlier shorter to invoke these APIs for a very common case.
Also, do some minor other coding style updates, and add assert()s here
and there.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PID 1 to journald
And let's make use of it to implement two new unit settings with it:
1. LogLevelMax= is a new per-unit setting that may be used to configure
log priority filtering: set it to LogLevelMax=notice and only
messages of level "notice" and lower (i.e. more important) will be
processed, all others are dropped.
2. LogExtraFields= is a new per-unit setting for configuring per-unit
journal fields, that are implicitly included in every log record
generated by the unit's processes. It takes field/value pairs in the
form of FOO=BAR.
Also, related to this, one exisiting unit setting is ported to this new
facility:
3. The invocation ID is now pulled from /run/elogind/units/ instead of
cgroupfs xattrs. This substantially relaxes requirements of elogind
on the kernel version and the privileges it runs with (specifically,
cgroupfs xattrs are not available in containers, since they are
stored in kernel memory, and hence are unsafe to permit to lesser
privileged code).
/run/elogind/units/ is a new directory, which contains a number of files
and symlinks encoding the above information. PID 1 creates and manages
these files, and journald reads them from there.
Note that this is supposed to be a direct path between PID 1 and the
journal only, due to the special runtime environment the journal runs
in. Normally, today we shouldn't introduce new interfaces that (mis-)use
a file system as IPC framework, and instead just an IPC system, but this
is very hard to do between the journal and PID 1, as long as the IPC
system is a subject PID 1 manages, and itself a client to the journal.
This patch cleans up a couple of types used in journal code:
specifically we switch to size_t for a couple of memory-sizing values,
as size_t is the right choice for everything that is memory.
Fixes: #4089
Fixes: #3041
Fixes: #4441
|
| |
|
|
| |
Just the error check and message were wrong, otherwise the logic was OK.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SetLinger is authorized by the PolicyKit action "set-self-linger", if it is
not passed an explicit UID.
According to comments we were determining the default UID from the client's
session. However, user processes e.g. which are run from a terminal
emulator do not necessarily belong to a session scope unit. They may
equally be started from the elogind user manager [1][2]. Actually the
comment was wrong, and it would also have worked for processes
started from the elogind user manager.
Nevertheless it seems to involve fetching "augmented credentials" i.e.
it's using a racy method, so we shouldn't have been authenticating based
on it.
We could change the default UID, but that raises issues especially for
consistency between the methods. Instead we can just use the clients
effective UID for authorization.
This commit also fixes `loginctl enable-linger $USER` to match the docs
that say it was equivalent to `loginctl enable-linger` (given that $USER
matches the callers user and owner_uid). Previously, the former would not
have suceeded for unpriviliged users in the default configuration.
[1] It seems the main meaning of per-session scopes is tracking the PAM
login process. Killing that provokes logind to revoke device access. Less
circularly, killing it provokes getty to hangup the TTY.
[2] User units may be started with an environment which includes
XDG_SESSION_ID (presuambly GNOME does this?). Or not.
|
| |
|
|
|
|
|
| |
To maintain consistency with `loginctl user-status`, drop the fallback to
XDG_SESSION_ID for `loginctl enable-linger`. The fallback was unnecessary
and also incorrect: it passed the numeric value of the session identifier
as a UID value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's confusing that the bus API has aliases like "session/self" that return
an error based on ENXIO, when it also has methods that return e.g.
NO_SESSION_FOR_PID for the same problem. The latter kind of error includes
more specifically helpful messages.
"user/self" is the odd one out; it returns a generic UnknownObject error
when it is not applicable to the caller. It's not clear whether this was
intentional, but at first I thought it was more correct. More
specifically, user_object_find() was returning 0 for "user/self", in the
same situations (more or less) where user_node_enumerator() was omitting
"user/self". I thought that was a good idea, because returning e.g. -ENXIO instead
suggested that there _is_ something specific on that path. And it could be
confused with errors of the method being called.
Therefore I suggested changing the enumerator, always admitting that there
is a handler for the path "foo/self", but returning a specific error when
queried. However this interacts poorly with tools like D-Feet or `busctl`.
In either tool, looking at logind would show an error message, and then go
on to omit "user/self" in the normal listing. These tools are very useful,
so we don't want to interfere with them.
I think we can change the error codes without causing problems. The self
objects were not listed in the documentation. They have been suggested to
other projects - but without reference to error reporting. "seat/self" is
used by various Wayland compositors for VT switching, but they don't appear
to reference specific errors.
We _could_ insist on the link between enumeration and UnknownObject, and
standardize on that as the error for the aliases. But I'm not aware of any
practical complaints, that we returned an error from an object that didn't
exist.
Instead, let's unify the codepaths for "user/self" vs GetUserByPid(0) etc.
We will return the most helpful error message we can think of, if the
object does not exist. E.g. for "session/self", we might return an error
that the caller does not belong to a session. If one of the compositors is
ever simplified to use "session/self" in initialization, users would be
able to trigger such errors (e.g. run `gnome-shell` inside gnome-terminal).
The message text will most likely be logged. The user might not know what
the "session" is, but at least we'll be pointing towards the right
questions. I think it should also be clearer for development / debugging.
Unifying the code paths is also slightly helpful for auditing / marking
calls to sd_bus_creds_get_session() in subsequent commits.
|
| |
|
|
|
| |
The check is redundant as the whole block is only evaluated if
__IGNORE_pkey_mprotect is not defined. Change to #else.
|
| |
|
|
|
|
|
|
| |
Previously it was not possible to select which controllers to enable for
a unit where Delegate=yes was set, as all controllers were enabled. With
this change, this is made configurable, and thus delegation units can
pick specifically what they want to manage themselves, and what they
don't care about.
|
| | |
|
| |
|
|
|
| |
subtree_mask is own_mask | members_mask, let's make use of that to
shorten a few things
|
| |
|
|
| |
which v1-only
|
| |
|
|
| |
Follow-up for b835eeb4ec1dd122b6feff2b70881265c529fcdd.
|
| |
|
|
|
|
|
|
|
|
| |
Let's say that (size_t) -1 (i.e. SIZE_T_MAX) is equivalent to
"unbounded" ellipsation, i.e. ellipsation as NOP. In which case the
relevant functions become little more than strdup()/strndup().
This is useful to simplify caller code in case we want to turn off
ellipsation in certain code paths with minimal caller-side handling for
this.
|
| |
|
|
| |
Not that we need it, but let's do this as matter of completeness.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the dependencies Set* objects by Hashmap* objects, where
the key is the depending Unit, and the value is a bitmask encoding why
the specific dependency was created.
The bitmask contains a number of different, defined bits, that indicate
why dependencies exist, for example whether they are created due to
explicitly configured deps in files, by udev rules or implicitly.
Note that memory usage is not increased by this change, even though we
store more information, as we manage to encode the bit mask inside the
value pointer each Hashmap entry contains.
Why this all? When we know how a dependency came to be, we can update
dependencies correctly when a configuration source changes but others
are left unaltered. Specifically:
1. We can fix UDEV_WANTS dependency generation: so far we kept adding
dependencies configured that way, but if a device lost such a
dependency we couldn't them again as there was no scheme for removing
of dependencies in place.
2. We can implement "pin-pointed" reload of unit files. If we know what
dependencies were created as result of configuration in a unit file,
then we know what to flush out when we want to reload it.
3. It's useful for debugging: "elogind-analyze dump" now shows
this information, helping substantially with understanding how
elogind's dependency tree came to be the way it came to be.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was dropped in 89439d4fc0d29f04ac68432fd06ab84bc4e36e20. As a result, every
process that uses a hashmap allocates and then leaks the hashmap mempools.
The mempools are only allocated in the main thread, but we don't know where
the memory is used.
So let's check if we are the last thread and free the mempools then. This is
fairly heavy, because /proc/self/status has to be opened and parsed, but we do
it only when compiled for valgrind, i.e. not by default, and compared to running
under valgrind or asan, the extra cost is acceptable. The big advantage is that
we don't have to think or filter out this false positive.
As a micro-opt, cleanup is attempted only in the main thread. We could allow
any thread to check if it is the last one and perform cleanup, but that'd mean
that we'd have to _do_ the check in every thread. We don't use threads like
that, our non-main threads are always short-lived, so let's just accept the
possibility that we'll leak memory if a thread survives. The check is also
non-atomic, but it's called in a destructor of the main thread _and_ we do
cleanup only when there are no other threads, so the risk of some library
suddenly spawning another thread is very low. All in all, this is not perfect,
but should work in 999‰ of cases.
Fixes the following valgrind warning:
==22564== HEAP SUMMARY:
==22564== in use at exit: 8,192 bytes in 2 blocks
==22564== total heap usage: 243 allocs, 241 frees, 151,905 bytes allocated
==22564==
==22564== 4,096 bytes in 1 blocks are still reachable in loss record 1 of 2
==22564== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==22564== by 0x4F08A8C: mempool_alloc_tile (mempool.c:62)
==22564== by 0x4F08B16: mempool_alloc0_tile (mempool.c:81)
==22564== by 0x4EF8DE0: hashmap_base_new (hashmap.c:748)
==22564== by 0x4EF8ED9: internal_hashmap_new (hashmap.c:782)
==22564== by 0x11045D: test_hashmap_copy (test-hashmap-plain.c:87)
==22564== by 0x115722: test_hashmap_funcs (test-hashmap-plain.c:914)
==22564== by 0x10FC9D: main (test-hashmap.c:60)
==22564==
==22564== 4,096 bytes in 1 blocks are still reachable in loss record 2 of 2
==22564== at 0x4C2FB6B: malloc (vg_replace_malloc.c:299)
==22564== by 0x4F08A8C: mempool_alloc_tile (mempool.c:62)
==22564== by 0x4F08B16: mempool_alloc0_tile (mempool.c:81)
==22564== by 0x4EF8DE0: hashmap_base_new (hashmap.c:748)
==22564== by 0x4EF8EF8: internal_ordered_hashmap_new (hashmap.c:786)
==22564== by 0x10A2A0: test_ordered_hashmap_copy (test-hashmap-ordered.c:89)
==22564== by 0x10F70F: test_ordered_hashmap_funcs (test-hashmap-ordered.c:916)
==22564== by 0x10FCA2: main (test-hashmap.c:61)
==22564==
==22564== LEAK SUMMARY:
==22564== definitely lost: 0 bytes in 0 blocks
==22564== indirectly lost: 0 bytes in 0 blocks
==22564== possibly lost: 0 bytes in 0 blocks
==22564== still reachable: 8,192 bytes in 2 blocks
==22564== suppressed: 0 bytes in 0 blocks
v2:
- check if we are the main thread
v3:
- check if there are no other threads
|
| |
|
|
|
|
|
|
| |
Enable elogind-firstboot to set the keymap.
RFE:
https://github.com/elogind/elogind/issues/6346
|
| |
|
|
| |
Follow-up for 85e55d14dea66f5fe412ca8128487d5ea828b7b1.
|
| |
|
|
|
|
|
|
| |
- Remove the uaccess tag from /dev/dri/renderD*.
- Change the owning group from video to render.
- Change default mode to 0666.
- Add an option to allow users to set the access mode for these devices at
compile time.
|
| |
|
|
|
| |
- Remove uaccess tag from /dev/kvm.
- Change the default mode for /dev/kvm to 0666.
|
