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 _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
