Samba (precisely nmbd) slowing down boot process if there is no network

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version: 8.6
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN: bullseye
  • Kernel version | uname -a: 5.15.32-v7+
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3): RPi Zero 2 W (armv7l)
  • Power supply used | (EG: 5V 1A RAVpower): yes, original rpi power supply
  • SD card used | (EG: SanDisk ultra): Kingston Canvas Go! Plus

Additional Information (if applicable)

  • Software title | (EG: Nextcloud): Samba family (nmbd)
  • Was the software title installed freshly or updated/migrated? freshly
  • Can this issue be replicated on a fresh installation of DietPi? yes
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. install samba from dietpi-software in terminal
  2. turn off wifi
  3. reboot
  4. profit

Expected behaviour

  • normal boot, without stopping for a minute at nmbd trying to start

Actual behaviour

  • slow boot, waiting for nmbd to start for a minute or two

Extra details

  • if there is no internet/network connection I wouldn’t even start samba (and its friends), cause there is no reason,
    so I would check the internet/network connection
  • also if network connection is initialized after boot (user connected to wifi or plugged in cable), i should check again for samba and start it then
  • I have also checked this behaviour in 64 bit bullseye too, and it’s really annoying if you are running for example RetroPie (or anything which doesn’t require network or internet)
1 Like

You simply could disable autostart of SAMBA and just start it manually if needed.

The Samba server should actually not delay boot. It is started by dietpi-postboot (when installed via dietpi-software) which is an “idle” service and hence starts asynchroniously after the ordered systemd service startup process.

Also when started via systemd, it shouldn’t delay boot since no service or target depends/is ordered after the Samba server, AFAIK.

How are you (auto)starting RetroPie and how do you know that Samba is delaying it/other parts of the boot sequence?

That Samba does not quickly fail if no network is up (but hangs until 90 seconds default systemd timeout) however an issue regardless, but one that is out of our control. There would be a way to have nmbd “succeeding” early and then hanging asynchronously, but that might break smbd startup. There is not really a “wait forever until network is up, then start service” facility in systemd or DietPi: By default the related network targets is also waited for max 90 seconds. So if you usually start the system offline, it makes sense to start network-depending services manually, or create an own loop script around it.

I am autostarting RetroPie by its own autostart option (i don’t really know what is it exactly but i have tried it as a service too and it doesn’t make a difference). It slows down so much that I can just read the boot script when it is trying to start, as you have mentioned I have 90 secs. I have made a script to enable/disable samba and its friends, it is just weird for me that it is not solved automatically like i have written in the description.

That is common behaviour on server (!) systems: Usually, if a network-depending service is started while there is no network, it simply fails hard quickly. That Samba is trying it up to the timeout is not beautiful indeed, but a decision of the Samba developers or Debian package maintainers, which will have a reason. Somehow gracefully skipping a service when there is no network is indeed something I’ve never seen, they always fail, intentionally, to tell admins that there is something wrong. Usually you do not want to have a server with network services starting offline, but admins want to know when it is offline, see that in the logs and clear errors that this is the reason why services failed or the server wasn’t reachable at a certain time.

I’ve no idea the RetroPie autostart option works. Can you check whether it’s in /etc/rc.local or ~/.bashrc? If it does not switch to a new TTY, it is possible that the service start messages overlap with the RetroPie output (while RetroPie is not actually delayed). E.g. for Amiberry autostart option we switch to a different TTY to assure it does not mix with other console output, which can be also things like hardware detection, kernel messages and other things. If you find the RetroPie start command in one of the two scripts above, try to add chvt 3 (or sudo chvt 3) above the command and see if that helps.