1. If we exited emergency mode immediately, we don't want to have an
irreversible stop job still running for syslog.socket. I _suspect_ that
can't happen, but let's not waste effort working out exactly why it's
impossible and not just very improbable.
2. Similarly, it seems undesirable to have rescue.service and
emergency.service both running with an open FD of /dev/console, for
however short a period.
Note this commit only changes how the code is expressed; it does not change
the existence of any dependency.
The `Conflicts=` was added in 3136ec90, "Stop syslog.socket when entering
emergency mode". The discussion in the issue #266 raised concerns that
this might be needed for other units, but failed to point out why
syslog.socket is special. The reason is that syslog.socket has
DefaultDepedencies=no, so it does not get Requires=sysinit.target like
other socket units do. But syslog.service does require sysinit.target,
among other things.
We don't have many socket, path, or timer units with
DefaultDependencies=no, and I don't think any of the triggered services
have such additional hard dependencies as syslog.service does.
It is much less confusing if we keep this `Conflicts=` in the same file as
the `DefaultDependencies=no` which made it necessary.
The original aim of this commit is that starting machines.target from the
rescue shell would not kill the rescue shell and lock you out of the
system.
This is similar to commit 6579a622, for the conflict between
sysinit.target and the _emergency_ shell. That particular commit
introduced an ordering cycle and will need to be reverted and/or
fixed. This one does not, because it does not need to introduce any new
dependencies.
The reason why this commit is allowable also has it's own merit:
machines.target was not marked as AllowIsolate. Also, the point of
containers is to not escape them... I don't think we want to promote
machines.target as a default target or similar; you would generally want
some system service to allow you to shut down the machine, for example. I
don't see this approach used in CoreOS, nor in Fedora Atomic Host; we are
missing any positive examples of its utility.
Requires=basic.target / After=basic.target can be removed for the same
reason.
Why
---
The advantage of this is that starting sysinit.target from the emergency
shell will no longer kill the emergency shell and lock you out of the
system. Our docs already claimed that emergency.target was useful for
"starting individual units in order to continue the boot process in steps".
This resolves#6509 for my purposes.
Remaining limitation
--------------------
Starting getty.target will still kill the shell, and if you don't have a
root password you will then be locked out at that point. This is relevant
to distributions which patch the sulogin system to permit logins when the
root password is locked. Both Debian and RedHat used to follow this
behaviour! Debian have been discussing what they could replace it with at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806852
So this doesn't quite achieve perfection, but I think it's a worthwhile
change. It should be easier to understand the logic now it doesn't have
such a big hole in it. Repairing the sysinit stage of the boot is the main
reason we have emergency.target. And as discussed in the issue,
sysinit.target gets pulled in implicitly as soon as any DefaultDependencies
service is activated.
How
---
sysinit.target only needs to conflict with emergency.target. It didn't
need to conflict with emergency.service as well. In theory the conflicts
are pointless, we could just change the dependency of sysinit.target on
local-fs.target from Wants to Requires. However, doing so would mean that
when local-fs fails, the screen is flooded with yellow [DEPEND] failures.
That would hinder the poor unfortunate admin, so let's not do that.
There is no additional ordering requirement against emergency. If the
failure happens, the job for sysinit will be cancelled instantly. We don't
need to worry about when sysinit.target and its dependents would be
stopped, because sysinit waits for local-fs before it starts.
emergency.target is still necessarily stopped once we reach sysinit
(you can't express a one-way conflict in pure unit directives).
This is largely cosmetic... though perhaps it symbolizes that you're no
longer in Emergency Mode if System Initialization is successful ;-).
As a secondary advantage, the getty's which conflict on rescue.service now
need to conflict on emergency.service as well. This makes the system more
uniform and simpler to understand.
The only other effect this should have is that
`systemctl start emergency.target` is now practically the same as
`systemctl start rescue.target`. The only units this command will stop are
the conflicting getty units. Neither of those commands should ever be
used. E.g. they will not stop the gdm.service unit on Fedora 26.
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.]
