| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We used both, in fact "Devicetree" was more common. But we have a general rule
that we capitalize all words in names and also we have a DeviceTree=
configuration setting, which we cannot change. If we use two different
spelllings, this will make it harder for people to use the correct one in
config files. So use the "DeviceTree" spelling everywhere.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since v256 we completely fail to boot if v1 is configured. Fedora 41 was just
released with v256.7 and this is probably the first major exposure of users to
this code. It turns out not work very well. Fedora switched to v2 as default in
F31 (2019) and at that time some people added configuration to use v1 either
because of Docker or for other reasons. But it's been long enough ago that
people don't remember this and are now very unhappy when the system refuses to
boot after an upgrade.
Refusing to boot is also unnecessarilly punishing to users. For machines that
are used remotely, this could mean somebody needs to physically access the
machine. For other users, the machine might be the only way to access the net
and help, and people might not know how to set kernel parameters without some
docs. And because this is in systemd, after an upgrade all boot choices are
affected, and it's not possible to e.g. select an older kernel for boot. And
crashing the machine doesn't really serve our goal either: we were giving a
hint how to continue using v1 and nothing else.
If the new override is configured, warn and immediately boot to v1.
If v1 is configured w/o the override, warn and wait 30 s and boot to v2.
Also give a hint how to switch to v2.
https://bugzilla.redhat.com/show_bug.cgi?id=2323323
https://bugzilla.redhat.com/show_bug.cgi?id=2323345
https://bugzilla.redhat.com/show_bug.cgi?id=2322467
https://www.reddit.com/r/Fedora/comments/1gfcyw9/refusing_to_run_under_cgroup_01_sy_specified_on/
The advice is to set systemd.unified_cgroup_hierarchy=1 (instead of removing
systemd.unified_cgroup_hierarchy=0). I think this is easier to convey. Users
who are understand what is going on can just remove the option instead.
The caching is dropped in cg_is_legacy_wanted(). It turns out that the
order in which those functions are called during early setup is very fragile.
If cg_is_legacy_wanted() is called before we have set up the v2 hierarchy,
we incorrectly cache a true answer. The function is called just a handful
of times at most, so we don't really need to cache the response.
|
| |
|
|
| |
For justification, see 3f9a0a522f2029e9295ea5e9984259022be88413.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new setting allows unsharing the pid namespace in a unit. Because
you have to fork to get a process into a pid namespace, we fork in
systemd-executor to get into the new pid namespace. The parent then
sends the pid of the child process back to the manager and exits while
the child process continues on with the rest of exec_invoke() and then
executes the actual payload.
Communicating the child pid is done via a new pidref socket pair that is
set up on manager startup.
We unshare the PID namespace right before the mount namespace so we
mount procfs correctly. Note PrivatePIDs=yes always implies MountAPIVFS=yes
to mount procfs.
When running unprivileged in a user session, user namespace is set up first
to allow for PID namespace to be unshared. However, when running in
privileged mode, we unshare the user namespace last to ensure the user
namespace does not own the PID namespace and cannot break out of the sandbox.
Note we disallow Type=forking services from using PrivatePIDs=yes since the
init proess inside the PID namespace must not exit for other processes in
the namespace to exist.
Note Daan De Meyer did the original work for this commit with Ryan Wilson
addressing follow-ups.
Co-authored-by: Daan De Meyer <daan.j.demeyer@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
The same item is described below.
Also reflow some paragraphs (presumably indented with emacs, which does this
wrong).
|
| | |
|
| |\
| |
| | |
logind: drop new delay-weak inhibitor
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It wasn't actually requested, just a misunderstanding, so drop it.
Fixes https://github.com/systemd/systemd/issues/34091
Follow-up for 804874d26ac73e0af07c4c5d7165c95372f03f6d
|
| | |
| |
| |
| | |
ExtraFileDescriptors= yet
|
| | | |
|
| |\ \
| | |
| | | |
Change systemd-nspawn man page to strongly recommend private users
|
| | | |
| | |
| | |
| | |
| | | |
Both spellings were used, but the dictionary says that "lightweight"
is the standard spelling.
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | | |
core/manager: Deprecate StartAuxiliaryScope() method
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The method was added with migration of resources in mind (e.g. process's
allocated memory will follow it to the new scope), however, such a
resource migration is not in cgroup semantics. The method may thus have
the intended users and others could be guided to StartTransientUnit().
Since this API was advertised in a regular release, start the removal
with a deprecation message to callers.
Eventually, the goal is to remove the method to clean up DBus API and
simplify code (removal of cgroup_context_copy()).
Part of DBus docs is retained to satisfy build checks.
|
| | | |
| | |
| | |
| | |
| | | |
As per: https://github.com/systemd/systemd/pull/34325
And: https://github.com/systemd/systemd/issues/34323
|
| |/ /
| |
| |
| | |
This reverts commit 0a40325573b91ea71070653865f7f6a9cada2bef.
|
| | |
| |
| |
| | |
See: https://github.com/systemd/systemd/pull/34548
|
| | |
| |
| |
| |
| |
| | |
We need to make sure the presets from /usr/lib/systemd/user-preset
are applied as well. Currently only the ones from
/usr/lib/systemd/system-preset are applied.
|
| | | |
|
| | |
| |
| |
| | |
Follow-up for dcc359010c0a0d8366ade913bad72acb98f4f0ef.
|
| |/
|
|
|
|
|
| |
Let's make the risk of accidental misuse, and mark lines that shall be
covered by --purge with an explicit new flag "$".
See: #33349
|
| | |
|
| | |
|
| |
|
|
| |
Follow-up for 7a3a49386cc49d3971531ea24efb84232c05cc86.
|
| | |
|
| |\
| |
| | |
resolve: support 'resolvconf -p'
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we manually hardcoded $LISTEN_FDNAMES to "varlink" in various
varlink service units we ship, even though FileDescriptorName=varlink
is specified in associated socket units already, because
FileDescriptorName= is currently silently ignored when combined with
Accept=yes. Let's step away from this, which seems saner.
Note that this is technically a compat break, but a mostly negligible
one as there shall be few users setting FileDescriptorName= but
still expecting LISTEN_FDNAMES=connection in the actual executable.
Preparation for #34080
|
| |
|
|
|
| |
If there's no systemd installation in the image, assume the unified
cgroup hierarchy.
|
| |
|
|
|
| |
Follow-up for 089bef66316e5bdc91b9984148e5a6455449c1da.
Prompted by https://github.com/systemd/systemd/issues/33619#issuecomment-2257576579.
|
| | |
|
| | |
|
| |
|
|
| |
Follow-up for 28f1f1a5e652508d6e61ace8918e8b831e4b62b4
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
