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
install samba from dietpi-software in terminal
turn off wifi
reboot
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)
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.