Bug#858818: please consider implementing or at least documenting a headless-friendly emergency target

[Marc Haber]

Package: systemd
Version: 232-21
Severity: wishlist

Hi,

in the pre-systemd era, a system would continue booting even after an
error. This frequently resulted in a crippled, but running system
which allowed a (sometimes crippled) remote login which allowed fixing
things from remote without having to access the console.

On the other hand, systemd tends to jump into emergency.target at the
slightest possibility of an issue with booting, the the default
emergency.service is a train wreck when it comes to having a system in
a corporate datacenter, especially in a cheap one: It demands that one
enters the root password on a console. This needs (a) access to the
console, and (b) to the root password.

A console is debateably accessible in the majority of cases. I do,
however, have a number of systems in cheap datacenters where I either
need to rent a console server to get access to the console or to
actually talk to a human who types commands into the console.

In many companies, the access to the actual root password is severely
restricted because you usually do your admin tasks with sudo after
logging in as a mere user. The actual root password is often in a safe
with the key being unter management control, or it is divided into
parts that are stored with different individuals so that you need to
wake all of them to use the root password.

Please consider at least documenting a way to get a more
admin-friendly emergency mode, which could include one or more of the
following measures:

(1) allow regular login in emergency mode
Instead of using sulogin in the emergency target, one could use a
regular login process which would allow logging in as a regular user
and use sudo to get root privileges. I do admit that systems can be so
broken that sudo won't work, but being deprived of the actual _chance_
for that to work is frustrating.

(2) try to bring the network up and start an (emergency) sshd
I have had cases where the system boot was aborted because /var could
not be mounted. In those cases, it would have been possible to ssh in
if the system had bothered to try starting sshd. This used to be the
case in the pre-systemd era, and I'd love to get this possibility back.

In the ideal wishlist case, this would be implemented either through
trivial configuration (such as, for example, systemd enable
emergency-login.service, systemd enable emergency-ssh.service), or it
would be at least documented how to achive this behavior.

Documentation of this is especially important since a systemd user
usually wants to avoid the knee-jerk "you're doing it wrong, take a
hike" reaction that is so common when one talks about a systemd issue
while having been creative with system configuration.

Please consider having a "Debian way" of making Debian great again for
datacenter usage.

Greetings
Marc