dietpi-boot.service taking 40+ seconds on rpi3B and pinea64 Topic is solved
Re: dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
I could try some package recording, but not that weekend as I will be out. So probably next week I will be able to check.
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Re: dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
Hi,
i did 2 reboots today. Both are done within an hour.
first one
second one
Will do some logging on my router this week
i did 2 reboots today. Both are done within an hour.
first one
Code: Select all
root@DietPi3:~# systemd-analyze blame
1.236s dietpi-preboot.service
1.107s dev-mmcblk0p2.device
987ms dietpi-boot.service
Code: Select all
root@DietPi3:~# systemd-analyze blame
33.214s dietpi-boot.service
1.230s dietpi-preboot.service
1.100s dev-mmcblk0p2.device
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Re: dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
I just recognised that on our current images, systemd-timesyncd is enabled on first boot. I'll search through the code, but is is probably enabled in your case as well? systemctl is-enabled systemd-timesyncd
I'll run some tests if it causes delays when time sync has been done already, before (when restarting the service) another sync is done.
Okay verified:
- DietPi-PREP does not touch the time sync mode (systemd-timesyncd is enabled)
- On first boot, first time sync happens automatically then once systemd-timesyncd finds connection.
- Then on login, DietPi-Login forces another time sync, restarting the service.
- Then DietPi-Software applies the chosen time sync mode during first run installs.
Hence issues due to two closely running time syncs can only happen on first boot. But needs cleanup:
- systemd-timesyncd should be disabled on fresh images, to match defaults
- Prior to login and such, the early firstrun script needs to apply the chosen time sync mode (and server) and enable the service, if chosen
- So DietPi-Login already handles things according to the chosen settings
I'll run some tests if it causes delays when time sync has been done already, before (when restarting the service) another sync is done.
Okay verified:
- DietPi-PREP does not touch the time sync mode (systemd-timesyncd is enabled)
- On first boot, first time sync happens automatically then once systemd-timesyncd finds connection.
- Then on login, DietPi-Login forces another time sync, restarting the service.
- Then DietPi-Software applies the chosen time sync mode during first run installs.
Hence issues due to two closely running time syncs can only happen on first boot. But needs cleanup:
- systemd-timesyncd should be disabled on fresh images, to match defaults
- Prior to login and such, the early firstrun script needs to apply the chosen time sync mode (and server) and enable the service, if chosen
- So DietPi-Login already handles things according to the chosen settings
Re: dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
So finally I was able to trace the connection today. Attached the result. The filter is set for all communication from and to the RPi3B+. Capturing was started short before boot.
192.168.0.1 is my Internet Router / NTP Server
192.168.0.11 is my PiHole running DHCP + DNS
192.168.0.12 is the RPi3B+ client (hanging on boot)
192.168.0.31 my desktop computer Win10
at 2 sec you see the DHCP request that get answered
at 30 sec you see the NTP request.
Nothing happen in between, accept me trying to connect on port 22

192.168.0.1 is my Internet Router / NTP Server
192.168.0.11 is my PiHole running DHCP + DNS
192.168.0.12 is the RPi3B+ client (hanging on boot)
192.168.0.31 my desktop computer Win10
at 2 sec you see the DHCP request that get answered
at 30 sec you see the NTP request.
Nothing happen in between, accept me trying to connect on port 22


Code: Select all
root@DietPi3:~# systemd-analyze blame
33.425s dietpi-boot.service
1.221s dietpi-preboot.service
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
Re: dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
Quite strange. Actually, systemd-timesyncd, when started, should always send NTP requests immediately. What I anyway wanted to change by times, is omitting the systemd-timesyncd service and instead start the binary /lib/systemd/systemd-timesyncd directly. This needs to be done within an output parser (read), since this is a foreground process then. But actually the systemd service should do exactly the same
.
