dietpi-boot.service taking 40+ seconds on rpi3B and pinea64 Topic is solved

[Joulinar]

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.

[Joulinar]

Hi,
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

second one

Code: Select all

root@DietPi3:~# systemd-analyze blame
         33.214s dietpi-boot.service
          1.230s dietpi-preboot.service
          1.100s dev-mmcblk0p2.device

Will do some logging on my router this week

[MichaIng]

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

[Joulinar]

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

Code: Select all

root@DietPi3:~# systemd-analyze blame
         33.425s dietpi-boot.service
          1.221s dietpi-preboot.service

[MichaIng]

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 .