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

Michael Biebl biebl at debian.org
Mon Mar 27 17:03:34 BST 2017

Am 27.03.2017 um 17:07 schrieb Marc Haber:
> Hi Felipe,
> thanks for your fast answer. I really appreciate your consideration.
> On Mon, Mar 27, 2017 at 11:47:40AM -0300, Felipe Sateler wrote:
>> On Mon, Mar 27, 2017 at 5:51 AM, Marc Haber
>> <mh+debian-packages at zugschlus.de> wrote:
>>> (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.
>> I suppose this would be as simple as replacing the `ExecStart`
>> directives of `emergency.service` to invoke login instead of sulogin.
>> Or the new[1] script could be enhanced to read that configuration from
>> somewhere.
>> [1] https://github.com/systemd/systemd/pull/5623
> I like the idea of a configurable script. But I also like the idea of
> having an emergency-login.service which could be used as a drop-in
> replacement, keeping emergency.service simple. But, it looks like, it
> is not as simple any more anyway.
> I am however worried that sulogin is used here instead of login for a
> reason. Does anybody reading thie remember why sulogin was invented in
> the first place? I have never understood why one would restrict login
> in this mode of operation.

You don't want to involve the whole PAM stack in an emergency situation.
PAM can be almost arbitrarily complex, involving network services (LDAP,
SSSD, etc.)

>>> (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.
>> I don't think this can work as long as ssh.service has
>> `DefaultDependencies=yes`, because that implies
>> `Requires=sysinit.target`, which is likely involved in the failure
>> that resulted in the emergency target being started.
> I guess that the ssh maintainer could be coaxed into including an
> sshd-emergency.service (maybe even socket activated for simplicity,
> possible with privilege separation disabled to heighten the chance of
> the service being successful) which systemd could use in this case. I
> do understand that doing this with the default sshd.service unit would
> be a challenge.

I don't think such a service needs to be part of ssh (or systemd for
that matter), it might actually be better if that was shipped by a
separate package, which can be installed on demand for cases likes your
(and is ideally maintained by users of such functionality).

Such a package could try to bring up the network by itself, by first
trying to directly run NM , ifup or even attempting a simple dhclient.
Directly, meaning not using the .service units which might have
dependencies which might not be satisfied by emergency.target/rescue.target.

Then it could try to start an SSH server (with possibly a minimal
config). It could even try different implementations, like openssh,
dropbear etc.

Again, I think this is not something which necessarily has to live in
the systemd package.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170327/ada001f8/attachment-0002.sig>

More information about the Pkg-systemd-maintainers mailing list