The condition should be satisfied only when users request to reconfigure
the link, and in that case, all request will be cancelled. Hence, it is
not necessary to process the request.
In most netlink handlers, we do the following,
1. decrease the message counter,
2. check the link state,
3. error handling,
4. update link state via e.g. link_check_ready().
The first two steps are mostly common, hence let's extract it.
Moreover, this is not only extracting the common logic, but provide a
strong advantage; `request_call_netlink_async()` assigns the relevant
Request object to the userdata of the netlink slot, and the request object
has full information about the message we sent. Hence, in the future,
netlink handler can print more detailed error message. E.g. when
an address is failed to configure, then currently we only show an
address is failed to configure, but with this commit, potentially we can
show which address is failed explicitly.
This does not change such error handling yet. But let's do that later.
Previously, even though all Request object are owned by Manager, they
do not have direct reference to Manager, but through Link or NetDev
object. But, as Link or NetDev can be NULL, we need to conditionalize
how to access Manager from Request with the type of the request.
This makes the way simpler, as now Request object has direct reference
to Manager.
This also rename request_drop() -> request_detach(), as in the previous
commit, the reference counter is introduced, so even if a reference of
a Request object from Manager is dropped, the object may still alive.
The naming `request_drop()` sounds the object will freed by the
function. But it may not. And `request_detach()` suggests the object
will not be managed by Manager any more, and I think it is more
appropreate.
This is just a cleanup, and should not change any behavior.
Currently, all Request object are always owned by Manager, and freed
when it is processed, especially, soon after a netlink message is sent.
So, it is not necessary to introduce the reference counter.
In a later commit, the Request object will _not_ be freed at the time
when a netlink message is sent, but assigned to the relevant netlink
slot as a userdata, and will be freed when a reply is received. So, the
owner of the Request object is changed in its lifetime. In that case, it
is convenient that the object has reference counter to avoid memleak or
double free.
This also renames e.g. request_process_address() -> address_process_request().
Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`,
as in the later commits, the function of processing request, e.g.
`address_process_request()`, will be assigned to the Request object when
it is created. And the request type will be used to distinguish and to
avoid deduplicating requests which do not have any assigned objects,
like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions
are mostly not necessary and redundant.
This is mostly cleanups and preparation for later commits, and should
not change any behavior.
This should not change any behavior, as req->netlink_handler is always
qdisc_handler or tclass_handler.
This is just a preparation for a later commit which introduces
request_call_netlink_async().
get_pretty_hostname() so far had semantics not in line with our usual
ones: the return parameter was actually freed before the return string
written into it, because that's what parse_env_file() does. Moreover,
when the value was not set it would return NULL but succeed.
Let's normalize this, and only fill in the return value if there's
something set, and never read from it, like we usually do with return
parameter, and in particular those named "ret_xyz".
The existing callers don't really care about the differences, but it's
nicer to normalize behaviour to minimize surprises.
so the CLI interface is now similar to `systemctl`, i.e. if no unit name
suffix is provided, assume `.service`.
Fixes: #20492
Before:
```
$ systemd-cgls --unit user@1000
Failed to query unit control group path: Invalid argument
Failed to list cgroup tree: Invalid argument
```
After:
```
$ build/systemd-cgls --unit user@1000
Unit user@1000.service (/user.slice/user-1000.slice/user@1000.service):
├─session.slice (#4939)
│ ├─pipewire-pulse.service (#5203)
│ │ └─7711 /usr/bin/pipewire-pulse
...
```
Unprivileged overlayfs is supported since Linux 5.11. The only
change needed to get ExtensionDirectories to work is to avoid
hard-coding the staging directory to the system manager runtime
directory, everything else just works (TM).
This mirrors a similar check in Linux kernel 5.16
(9dcc38e2813e0cd3b195940c98b181ce6ede8f20) that raised the
RLIMIT_MEMLOCK to 8M.
This change does two things: raise the default limit for nspawn
containers (where we try to mimic closely what the kernel does), and
bump it when running on old kernels which still have the lower setting.
Fixes: #16300
See: https://lwn.net/Articles/876288/
The first ExecStartPre or the first ExecStart commands would get the metadata,
but not the subsequent ones. Also check that we do not pass it in
ExecStartPost.
This fixes the following case:
OnFailure= would be spawned correctly, but OnSuccess= would be
spawned without the MONITOR_* metadata, because we'd "collect" the unit
that started successfully. So let's block cleanup while we have a job
running for the handler. The job cannot last infinitely, so at some point
we'll be able to collect both.
We already logged what we are spawning, but not so much why. Let's
add this, so it's easier to distinguish execstartpre/execstart/execstartpost
and such.
The test would fail when the the same handler was used for multiple
*failing* units. We need to call 'reset-failed' to let the manager forget
about the earlier ones.
systemd-analyze log-target console is removed, because it's easier to follow
the logs if logging it to the journal.
Remove the list logic, and simply skip passing metadata if more than one
unit triggered an OnFailure/OnSuccess handler.
Instead of a single env var to loop over, provide each separate item
as its own variable.
Fixes https://github.com/systemd/systemd/issues/22370
Backward incompatible change to avoid returning 'skipped' if a condition causes
a job activation to be skipped when using StartUnitWithFlags().
Job results are broadcasted, so it is theoretically possible that existing
software could get confused if they see this result.
Replaces https://github.com/systemd/systemd/pull/22369
This stuff is sufficiently different from the rest of main.c, let's move
it to its own .c/.h file, to make main.c a bit shorter.
No code changes, just some refactoring.
The only piece missing was to somehow make /proc appear in the
new user+mount namespace. It is not possible to mount a new
/proc instance, not even with hidepid=invisible,subset=pid, in
a user namespace unless a PID namespace is created too (and also
at the same time as the other namespaces, it is not possible to
mount a new /proc in a child process that creates a PID namespace
forked from a parent that created a user+mount namespace, it has
to happen at the same time).
Use the host's /proc with a bind-mount as a fallback for this
case. User session services would already run with it, so
nothing is lost.
The function has nothing to do with any Manager object, hence drop that
from the name. And it actually looks something up by handle *action* not
by *handle*, hence the old name was a bit misnomer. Let's call it
handle_action_lookup(), as it queries handle action metainfo for a
handle action.
Also, let's make sure it behaves more like our usual functions that
lookup some fixed data from some enum value/int: let's return NULL if we
don't find it.
Yu Watanabe
Luca Boccassi
Clyde Byrd III
Lennart Poettering
Frantisek Sumsal
Temuri Doghonadze
Zbigniew Jędrzejewski-Szmek
licunlong