Launch sshd more early in the boot sequence of FreeBSD systems

I had the first official presentation of my ADC/DAC unit controller project based on BeagleBone Black’s running FreeBSD - see the CyNet scheme below.

I faced a problem with the NFS client, which was sort of a home made one. In the hurry, I forgot to deactivate the mount directive of a NFS share in /etc/fstab, and when I started the BeagleBone Black just before the presentation, it was not connected to its home network and it hang at that point. I built it into a very tight box and there was no place anymore for the FTDI serial connector. Now, since sshd(8) is usually loaded as one of the last services, I was effectively locked out of the BBB. Fortunately, I overcame the problem by simulating the NFS share with my notebook and after restart, I was able to fix the /etc/fstab right before the actual presentation began, so nobody saw that I was in serious trouble - anyway, I would prefer to never become that nervous again.

The actual question is, why sshd has been set to start so very late in the booting process? If I want to put autonomous ARM devices somewhere into the field, then any hick-up in the startup sequence would leave me locked out. The short answer is that a late start of sshd may be somehow beneficial for FreeBSD desktop setups. However, that is neither the present use-case nor do I exactly understand why a Desktop user would care about when sshd is starting up.

Since the solution is quite easy, it is not necessary to start an eternal war of opinions on that. In order to make sshd starting-up more early in the boot sequence of FreeBSD systems, I need to change the respective startup script by the way of the following sed command:

# BEFORE: mountcritremote/" /back/etc/rc.d/sshd

Thereby, sshd is up and running right after the firewall (here ipfw(8)) was set up and activated.


Copyright © Dr. Rolf Jansen - 2019-02-24 17:20:47