1

On a systemd machine (e.g. Debian), whenever I issue a reboot, among the very first things that get killed is sshd. This wasn't the case in the not-so-great-but-also-not-too-bad sysvinit days, where I could still watch and sometimes fix issues going wrong during a reboot via SSH.

I'd be fine with sshd to not get sent a TERM signal at all or ideally as one of the very last processes, even after network has been shut down. Is there a way to achieve this with systemd?

I'd also be interested in a way to make sshd get started as one of the first services, but that's less of a priority.

al.
  • 925
  • 6
  • 17
  • Is it Debian, or not-Debian? Because, Debian (and Ubuntu and other Debian derivatives) does many things (including systemd) very strangely, so you and the people who might answer this question must take that into account. – Michael Hampton Apr 08 '19 at 00:10
  • I can't see the large strange differences wrt systemd between e.g. Debian and Arch Linux. For the question it really doesn't matter. I'm using Debian and Arch, but if there is a distro that behaves like I described, I'm happy to get a pointer to it and figure out myself what they're doing. – al. Apr 08 '19 at 12:10

1 Answers1

1

What are you going to observe and accomplish in 2 seconds? That is the time I observe a shutdown taking in its entirety: from terminating services, ifdown interfaces, unmount file systems, and TERM all processes. I tested with Debian Stretch on Google Cloud, built on 20190326.

Stopping services takes out their slices, and it is done in parallel. Their process tree including your sessions are rapidly terminated. I'm not aware of a configuration that will output anything useful before your session is gone.

You can have events logged via journald with Storage=persistent, or possibly sent to a remote system with systemd-journal-remote. Logs from the previous boot can be retrieved with journalctl -b -1. Either get back on the rebooted system with ssh or console, or look at remote logs.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • 1
    I think he is referring to the situation when something goes wrong during shutdown (which does happen occasionally). – Michael Hampton Apr 08 '19 at 13:59
  • Then console access (hypervisor, BMC) to the host, check the journal, fix things, and forcibly power it off if necessary. What recovery is possible depends on which failure mode. I have yet to see one where sessions still survive but shutdown failed. – John Mahowald Apr 08 '19 at 14:20
  • Michael Hampton is correct, I'm trying to debug embedded systems that don't reliably shut down and have no persistent logging by default. I can add a console on demand, but that doesn't scale. This type of debugging was never a problem with sysvinit. Remote journal is an option, thanks for suggesting. – al. Apr 09 '19 at 18:39
  • I rarely see such a worthless answer. Deserves -5 votes. Try rebooting an SBC or embedded system in 2 seconds. – user206746 Sep 13 '22 at 11:50