For pluggable ttys such as USB serial devices, the getty is restarted
and exits in a loop until the remove event reaches systemd. Under
certain circumstances the restart loop can overload the system in a
way that prevents the remove event from reaching systemd for a long
time (e.g. at least several minutes on a small embedded system).
Use the default RestartSec to prevent the restart loop from
overloading the system. Serial gettys are interactive units, so
waiting an extra 100ms really doesn't make a difference anyways
compared to the time it takes the user to log in.
Currently after exiting rescue shell we isolate default target. User
might want to isolate to some other target than default one. However
issuing systemctl isolate command to desired target would bring system
to default target as a consequence of running ExecStopPost action.
Having common ancestor for rescue shell and possible followup systemctl
default command should fix this. If user exits rescue shell we will
proceed with isolating default target, otherwise, on manual isolate,
parent shell process is terminated and we don't isolate default target,
but target chosen by user.
Suggested-by: Michal Schmidt <mschmidt@redhat.com>
As Zbigniew pointed out a new ConditionFirstBoot= appears like the nicer
way to hook in systemd-firstboot.service on first boots (those with /etc
unpopulated), so let's do this, and get rid of the generator again.
A new tool "systemd-firstboot" can be used either interactively on boot,
where it will query basic locale, timezone, hostname, root password
information and set it. Or it can be used non-interactively from the
command line when prepareing disk images for booting. When used
non-inertactively the tool can either copy settings from the host, or
take settings on the command line.
$ systemd-firstboot --root=/path/to/my/new/root --copy-locale --copy-root-password --hostname=waldi
The tool will be automatically invoked (interactively) now on first boot
if /etc is found unpopulated.
This also creates the infrastructure for generators to be notified via
an environment variable whether they are running on the first boot, or
not.
We really don't want these in containers as they provide a too lowlevel
look on the system.
Conditionalize them with CAP_SYS_RAWIO since that's required to access
/proc/kcore, /dev/kmem and similar, which feel similar in style. Also,
npsawn containers lack that capability.
npsawn containers generally have CAP_MKNOD, since this is required
to make PrviateDevices= work. Thus, it's not useful anymore to
conditionalize the kmod static device node units.
Use CAP_SYS_MODULES instead which is not available for nspawn
containers. However, the static device node logic is only done for being
able to autoload modules with it, and if we can't do that there's no
point in doing it.
Reported by Gerardo Exequiel Pozzi:
Looks like [commit a4a878d0] also changes a unrelated file
(units/local-fs.target) [partially]reverting the commit
40f862e3 (filesystem targets: disable default dependencies)
The side effect, at least in my case is that the "nofail" option in both
"crypttab" and "fstab" has partial effect does the default timeout
instead of continue normal boot without timeout.
In a normal running system, non-passive targets and units used during
early bootup are always started. So refusing "manual start" for them
doesn't make any difference, because a "start" command doesn't cause
any action.
In early boot however, the administrator might want to start on
of those targets or services by hand. We shouldn't interfere with that.
Note: in case of systemd-tmpfiles-setup.service, really running the
unit after system is up would break the system. So e.g. restarting
should not be allowed. The unit has "RefuseManualStop=yes", which
prevents restart too.
networkd-wait-online should never exist in the default transaction,
unless explicitly enable or pulled in via things like NFS. However, just
enabling networkd shouldn't enable networkd-wait-online, since it's
common to use the former without the latter.
The DefaultInstance= name is used when enabling template units when only
specifying the template name, but no instance.
Add DefaultInstance=tty1 to getty@.service, so that when the template
itself is enabled an instance for tty1 is created.
This is useful so that we "systemctl preset-all" can work properly,
because we can operate on getty@.service after finding it, and the right
instance is created.
The only update service we really need to guard like this is
systemd-tmpfiles-setup.service since if invoked manually might create
/var/run/nologin and thus blocking the user from login. The other
services are pretty much idempotent and don't suffer by this problem,
hence let's simplify them.
With this in place RPMs can make sure that whatever they drop in is
immeidately applied, and not delayed until next reboot.
This also moves systemd-sysusers back to /usr/bin, since hardcoding the
path to /usr/lib in the macros would mean compatibility breaks in
future, should we turn sysusers into a command that is actually OK for
people to call directly. And given that that is quite likely to happen
(since it is useful to prepare images with its --root= switch), let's
just prepare for it.
This new condition allows checking whether /etc or /var are out-of-date
relative to /usr. This is the counterpart for the update flag managed by
systemd-update-done.service. Services that want to be started once after
/usr got updated should use:
[Unit]
ConditionNeedsUpdate=/etc
Before=systemd-update-done.service
This makes sure that they are only run if /etc is out-of-date relative
to /usr. And that it will be executed after systemd-update-done.service
which is responsible for marking /etc up-to-date relative to the current
/usr.
ConditionNeedsUpdate= will also checks whether /etc is actually
writable, and not trigger if it isn't, since no update is possible then.
In order to support offline updates to /usr, we need to be able to run
certain tasks on next boot-up to bring /etc and /var in line with the
updated /usr. Hence, let's devise a mechanism how we can detect whether
/etc or /var are not up-to-date with /usr anymore: we keep "touch
files" in /etc/.updated and /var/.updated that are mtime-compared with
/usr. This means:
Whenever the vendor OS tree in /usr is updated, and any services that
shall be executed at next boot shall be triggered, it is sufficient to
update the mtime of /usr itself. At next boot, if /etc/.updated and/or
/var/.updated is older than than /usr (or missing), we know we have to
run the update tools once. After that is completed we need to update the
mtime of these files to the one of /usr, to keep track that we made the
necessary updates, and won't repeat them on next reboot.
A subsequent commit adds a new ConditionNeedsUpdate= condition that
allows checking on boot whether /etc or /var are outdated and need
updating.
This is an early step to allow booting up with an empty /etc, with
automatic rebuilding of the necessary cache files or user databases
therein, as well as supporting later updates of /usr that then propagate
to /etc and /var again.
We install two sysctl snippets ourselves, hence the condition will
always trigger, so no point in tryng to optimize things with this, it
just will make things slower, if anything.
There's no point in conditionalizing systemd-tmpfiles at boot, since we
ship tmpfiles snippets ourselves, hence they will always trigger anyway.
Also, there's no reason to pull in local-fs.target from the service,
hence drop that.
There might be implementations around where the network-online logic
might not talk to any network configuration service (and thus not have
to wait for it), hence let's explicitly order network-online.target
after network.target to avoid any ambiguities.
network-pre.target is a passive target that should be pulled in by
services that want to be executed before any network is configured (for
example: firewall scrips).
network-pre.target should be ordered before all network managemet
services (but not be pulled in by them).
network-pre.target should be order after all services that want to be
executed before any network is configured (and be pulled in by them).
Also, rename ProtectedHome= to ProtectHome=, to simplify things a bit.
With this in place we now have two neat options ProtectSystem= and
ProtectHome= for protecting the OS itself (and optionally its
configuration), and for protecting the user's data.
Either become uid/gid of the client we have been forked for, or become
the "systemd-bus-proxy" user if the client was root. We retain
CAP_IPC_OWNER so that we can tell kdbus we are actually our own client.
ReadOnlySystem= uses fs namespaces to mount /usr and /boot read-only for
a service.
ProtectedHome= uses fs namespaces to mount /home and /run/user
inaccessible or read-only for a service.
This patch also enables these settings for all our long-running services.
Together they should be good building block for a minimal service
sandbox, removing the ability for services to modify the operating
system or access the user's private data.
Rely on modules being built-in or autoloaded on-demand.
As networkd is a network facing service, we want to limits its capabilities,
as much as possible. Also, we may not have CAP_SYS_MODULE in a container,
and we want networkd to work the same there.
Module autoloading does not always work, but should be fixed by the kernel
patch f98f89a0104454f35a: 'net: tunnels - enable module autoloading', which
is currently in net-next and which people may consider backporting if they
want tunneling support without compiling in the modules.
Early adopters may also use a module-load.d snippet and order
systemd-modules-load.service before networkd to force the module
loading of tunneling modules.
This sholud fix the various build issues people have reported.
