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
~/.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.