IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The pair is similar to remote-fs.target and remote-fs-pre.target. Any
cryptsetup devices which require network shall be ordered after
remote-cryptsetup-pre.target and before remote-cryptsetup.target.
Normally this happens automatically, but if it happened that both targets were
pulled in, even though there were no cryptsetup units, they could be started
in reverse order, which would be somewhat confusing. Add an explicit ordering
to avoid this potential issue.
This new target is a passive unit, hence it is supposed to be pulled in
to the transaction by the service that wants to block login on the
console (e.g. text version of initial-setup). Now both getty and
serial-getty are ordered after this target.
https://lists.freedesktop.org/archives/systemd-devel/2015-July/033754.html
and the same for hibernate.target and hybrid-sleep.target.
Tested with both sucessful and unsuccessful suspends. The result of the
start job was correct in both cases. Closes#6419 (a regression in v233
and v234).
> suspend is unsual for a target, because it has to stop itself once it's
> started. Otherwise you couldn't start it again, so you could only suspend
> once! Currently that's implemented using BindsTo=systemd-sleep.service.
> Meaning it pulls in systemd-sleep.service to do the actual suspend, and
> then de-activates afterwards. But the behaviour of BindsTo was changed
> recently (not without some issues during development) - maybe this bug
> is caused by poettering/systemd@631b676 which I think was added in
> release v233.
>
> sleep.target (see man systemd.special) has the same need, but it
> implements it differently. It simply has StopWhenUnneeded=yes.
This commit switches suspend.target etc. to the approach used by
sleep.target.
Since hotplugs happen as soon as udevd is started, there is not much sense
in giving udev-trigger an After= dependency on any service. The device
could be hotplugged before coldplug starts.
This is intended to avoid the race window where we create the hwdb with
the wrong selinux context (then fix it up afterwards).
https://github.com/systemd/systemd/issues/3458#issuecomment-322444107
> Note that console-getty.service as more uses than just containers. The
> idea is that it may be used as alternative to the whole VC/logind stuff,
> if all you need is a console on /dev/console, even on physical devices.
This means we want to remove RestartSec=0, for serial systems.
See 4bf0432 "units/serial-getty@.service: use the default RestartSec".
The traditional runlevel 1 is "single user mode", and shuts down all but
the main console. In systemd, rescue.target provides runlevel1.target.
But it did not shut down logins on secondary consoles... if systemd was
running in a container.
I don't think we strictly need to change this. But when you look at both
container-getty@.service and getty@.service, you see that both have
IgnoreOnIsolate, but only the latter has Conflicts=rescue.service.
This also makes rescue.target in a container consistent with
emergency.target. In the latter case, the gettys were already stopped,
because they have a Requires dependency on sysinit.target.
Currently we have 4 getty services. 1 has a BindsTo dependency on a
device unit. 3 have ConditionPathExists, but the reason is different in
every single one.
* Add comment to console-getty@.service (see commit 1b41981d)
* getty@.service is already commented
* container-getty.service is not strictly correct, as I realized while
trying to compose a comment. Reported as #6584.
* Containers don't use serial-getty@console.service,
they use console-getty.service instead, and suppress
scanning for kernel or virtualizer consoles.
* Nowadays gettys are started on *all* configured kernel consoles.
* except for the line printer console, because that's not a tty.
(Seriously. Search CONFIG_LP_CONSOLE).
* Revert "modprobe.d: ship drop-in to set bonding max_bonds to 0 (#6448)"
This reverts commit 582faeb461.
* Revert "units: set ConditionVirtualization=!private-users on journald audit socket (#6508)"
This reverts commit d2a1ba103b.
Some kdbus_flag and memfd related parts are left behind, because they
are entangled with the "legacy" dbus support.
test-bus-benchmark is switched to "manual". It was already broken before
(in the non-kdbus mode) but apparently nobody noticed. Hopefully it can
be fixed later.
Since busname units are only useful with kdbus, they weren't actively
used. This was dead code, only compile-tested. If busname units are
ever added back, it'll be cleaner to start from scratch (possibly reverting
parts of this patch).
Currently we set 4096 as maximum for number of stream connections that
we accept. However maximum number of file descriptors that systemd is
willing to accept from us is just 1024. This means we can't retain all
stream connections that we accepted. Hence bump the limit of fds in a
unit file so that systemd holds open all stream fds while we are
restarted.
New limit is set to 4224 (4096 + 128).
Make agetty started by *getty* units pass '-p' option to "login", so it
doesn't clear the environment and passes whatever was setup by systemd
to shells. This is needed especially for programs which are specified as
user shells, but won't read locale settings from anywhere but
environment.
[zj: cherry-pick just the second patch from the series, see discussion
on the pull request.]
In the initial design, foobar-wait-online.service would have
Requisite=foobar.service, so that foobar-wait-online.service could be enabled
unconditionally, irrespective of whether foobar.service itself is enabled.
Unfortunately this doesn't work too well:
1. the message about foobar-wait-online.service being skipped because of a
"missing dependency" *looks* like an is problem. This is mostly cosmetic,
but it also quite confusing. We generally don't want any messages of this
type during default boot.
2. it is impossible to start and wait for the network in an
implementation-agnostic way: systemctl start network-online.target, or
Wants/After=network-online.target in a unit don't work because pulling in
network-online.target pulls in foobar-wait-online.service, but it in turn
does not pull in foobar.service. During startup, foobar.service is pulled in
by multi-user.target, but not in a smaller transaction which does not
include multi-user.target.
This change means that *-wait-online.service should be installed through
presets, so that it can be enabled/disabled at will by the administrator.
Our own systemd-networkd-wait-online.service does this already, and
similar change has been requested for NetworkManager-wait-online.service
(https://bugzilla.redhat.com/show_bug.cgi?id=1455704).
This change should by mostly backwards-compatible, unless somebody has some
wait-online.service enabled, without having the corresponding network
implementation enabled, and they are relying on it not being started. I think
that's relatively unlikely because of issue 1. above, and I'm not aware of this
being the default in any distro. And being able to start the network in an
implementation-agnostic way is pretty important, see
https://bugzilla.redhat.com/show_bug.cgi?id=1452866.
/var can be on a remote filesystem, thus hooking it to local-fs.target is not correct.
Also, only install the mount unit when machined is enabled, because
machined is the one managing the underlying device, and thus makes no
sense without machined.
Fixes#1175
This patch ensures that session devices are saved for each session.
In order to make the revokation logic work when logind is restarted, the
session devices are now saved in the session state files and their respective
file descriptors sent to PID1's fdstore in order to keep them open accross
restart.
This is mandatory in order to keep the revokation logic working. Indeed in case
of input-devices, the same file descriptors must be shared by logind and a
given session controller in order EVIOCREVOKE to work otherwise multiple
sessions can have device access in parallel.
This should be the only remaining and missing piece for making logind fully
restartable.
Fixes: #1163
