# dietpi-boot.service taking 40+ seconds on rpi3B and pinea64
**URL:** https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772
**Category:** Troubleshooting
**Created:** [18 January 2020 21:40 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772 "2020-01-18T21:40:05Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [18 January 2020 21:40 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/1 "2020-01-18T21:40:05Z")
I am facing huge after-boot delay on fresh install of dietpi (brand new Transcend UHS-1 sdcard, official power supply) on rpi3B and pinea64
after reading MOTD, I tried **systemd-analyze blame** command:
```nohighlight
root@pihole:~# systemd-analyze blame
41.423s dietpi-boot.service
1.371s ddclient.service
1.234s dietpi-preboot.service
1.229s dev-mmcblk0p2.device
...
```
what should I do to minimize dietpi-boot.service time? đ€
hereâs my dietpi-boot.service:
```nohighlight
root@pihole:~# cat /etc/systemd/system/dietpi-boot.service
[Unit]
Description=DietPi-Boot
# Order 3
Requisite=dietpi-preboot.service
After=dietpi-preboot.service network.target
Before=getty-pre.target getty@tty1.service getty.target ssh.service dropbear.service
[Service]
Type=oneshot
RemainAfterExit=yes
StandardOutput=tty
ExecStart=/bin/dash -c '/DietPi/dietpi/boot 2>&1 | tee /tmp/dietpi-boot.log'
[Install]
WantedBy=multi-user.target
```
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [18 January 2020 22:09 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/2 "2020-01-18T22:09:40Z")
Hi,
many thanks for your report.
Itâs coming most likely from NTP time sync during boot. For testing purposes you could deactivate NTP time sync within dietpi.txt and reboot your system.
Similar was reported here
[https://dietpi.com/forum/t/systemd-timesyncd-hanging-for-40-seconds-during-boot/3729/1](https://dietpi.com/forum/t/systemd-timesyncd-hanging-for-40-seconds-during-boot/3729/1)
---
### Author:  [@att2](https://dietpi.com/forum/u/att2)
#### Post date: [19 January 2020 15:55 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/3 "2020-01-19T15:55:48Z")
Please read this :
[https://dietpi.com/forum/t/solved-tipp-for-always-super-fast-booting-dietpi-boot-service-type-forking/3763/1](https://dietpi.com/forum/t/solved-tipp-for-always-super-fast-booting-dietpi-boot-service-type-forking/3763/1)
Change the service to type âforkingâ !!!
No slow boot anymore!
---
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [19 January 2020 18:52 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/4 "2020-01-19T18:52:56Z")
> [@](#):
>
> Please read this :
>
> [[solved] tipp for always super fast booting : dietpi-boot.service type=forking !!!](https://dietpi.com/forum/t/solved-tipp-for-always-super-fast-booting-dietpi-boot-service-type-forking/3763/1)
>
>
> Change the service to type âforkingâ !!!
> No slow boot anymore!
tried this but no gain
disabled NTP on boot and it reduced to 5s
---
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [19 January 2020 19:01 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/5 "2020-01-19T19:01:19Z")
> [@](#):
>
> Hi,
> many thanks for your report.
>
> Itâs coming most likely from NTP time sync during boot. For testing purposes you could deactivate NTP time sync within dietpi.txt and reboot your system.
>
> Similar was reported here
>
> [systemd-timesyncd hanging for 40 seconds during boot](https://dietpi.com/forum/t/systemd-timesyncd-hanging-for-40-seconds-during-boot/3729/1)
thanks! this solved the issue đ
by disbaling NTP sync, should I be worried because I run pihole on my rpi3B?
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [19 January 2020 19:09 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/6 "2020-01-19T19:09:21Z")
Hi,
yes indeed, disabling NTP might not be the best idea as you are missing the time sync. But the question is, does it hurt your to wait for 40 seconds on boot? How often you are going to reboot? I personally decided by my own to keep NTP aktive as I reboot my prod system just rarely. As well I noticed that on some of my systems it seems to be gone after a few weeks. But still I have no clue why and how đ€
---
### Author:  [@att2](https://dietpi.com/forum/u/att2)
#### Post date: [19 January 2020 20:31 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/7 "2020-01-19T20:31:11Z")
> [@](#):
>
> > [@](#):
> >
> > Please read this :
> >
> > [[solved] tipp for always super fast booting : dietpi-boot.service type=forking !!!](https://dietpi.com/forum/t/solved-tipp-for-always-super-fast-booting-dietpi-boot-service-type-forking/3763/1)
> >
> >
> > Change the service to type âforkingâ !!!
> > No slow boot anymore!
>
> tried this but no gain
> disabled NTP on boot and it reduced to 5s
Did you do a âsystemctl daemon-reloadâ after changing the systemd config file to âforkedâ mode ?
And yes slow booting hurts a lot, especially on devices which are frequently turned on or off !!!
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [20 January 2020 15:04 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/8 "2020-01-20T15:04:10Z")
kamilmirza
I discovered the following, changing IP address from DHCP to STATIC seems to have a positive impact as well
**Ethernet set to DHCP**
```nohighlight
root@DietPi3:~# systemd-analyze blame
30.981s dietpi-boot.service
```
**Ethernet set to STATIC**
```nohighlight
root@DietPi3:~# systemd-analyze blame
1.941s dietpi-boot.service
```
Basically there is no need to disable NTP. Just switch to a static IP seems to fix it as well. At least on my RPi3B. However still a strange topic.
---
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [20 January 2020 21:15 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/9 "2020-01-20T21:15:59Z")
Joulinar
nope switching to STATIC IP did not help
```nohighlight
root@pihole:~# systemd-analyze blame
40.449s dietpi-boot.service
```
have rpi3B here, as well
NTP mode is at 2 (default)
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [20 January 2020 21:18 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/10 "2020-01-20T21:18:48Z")
still quite strange topic. it seems completely random. The only thing we know, it depends on NTP and how fast it can update. Be we donât know why NTP is hanging in our cases. đ€
btw: NTP mode for me is GateWay as my Router is providing this function. Anyway I guess this doesnât have any impact
---
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [20 January 2020 21:55 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/11 "2020-01-20T21:55:12Z")
Joulinar
well I tried setting NTP as Gateway but that failed earlier because my router was not responding to NTP requests when enabled
reconfigured NTP server on my router and changed dietpi NTP mode to Gateway, now its responding to NTP requests đ¶
boot time drastically reduced to 2-8 seconds đ
though DHCP is taking more time versus STATIC IP
with **DHCP IP**
```nohighlight
root@pihole:~# systemd-analyze blame
8.380s dietpi-boot.service
```
with **STATIC IP**
```nohighlight
root@pihole:~# systemd-analyze blame
2.358s dietpi-boot.service
root@pihole:~# journalctl -u systemd-timesyncd
-- Logs begin at Tue 2020-01-21 02:42:09 PKT, end at Tue 2020-01-21 02:50:02 PKT. --
Jan 21 02:42:11 pihole systemd[1]: Starting Network Time Synchronization...
Jan 21 02:42:12 pihole systemd[1]: Started Network Time Synchronization.
Jan 21 02:42:21 pihole systemd-timesyncd[532]: Synchronized to time server for the first time 192.168.0.1:123 (192.168.0.1). Jan 21 02:42:21 pihole systemd[1]: Stopping Network Time Synchronization...
Jan 21 02:42:21 pihole systemd[1]: systemd-timesyncd.service: Succeeded.
Jan 21 02:42:21 pihole systemd[1]: Stopped Network Time Synchronization.
```
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [20 January 2020 22:03 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/12 "2020-01-20T22:03:38Z")
ahh cool. so your system is now booting much faster and still have time sync activated. correct?
---
### Author:  [@kamilmirza](https://dietpi.com/forum/u/kamilmirza)
#### Post date: [21 January 2020 09:35 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/13 "2020-01-21T09:35:11Z")
> [@](#):
>
> ahh cool. so your system is now booting much faster and still have time sync activated. correct?
yes
> dietpi-config \> Advanced Options \> Time Sync Mode \> 2 : Boot + Daily
> dietpi-config \> Network Options: Misc \> NTP Mirror \> Gateway
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [22 January 2020 17:26 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/14 "2020-01-22T17:26:25Z")
I wonder why Type=forking changed anything⊠Currently it is Type=oneshot which should have exactly the same result: In both cases follow-up units can only start ofter the main process exited.
What I wonder as well is that the time sync is done as background job, hence it should not delay dietpi-boot finish. Looks like I need to do some testing to verify this.
However yeah it is generally recommended to set the NTP mirror to local gateway (router), which in 99% servers as NTP server with cache and is hence the way fastest solution. It must stay enabled, otherwise you will earlier or later run into issues when connecting to SSL/TLS resources and certificate timestamps do not match anymore.
Not sure if I got everything correct, does the router not serve as NTP server, if you disabled DHCP (enabled static IP)? There might be few routers which have some strict rules about this, but usually:
- Simply assign the same IP + gateway + DNS that you got via DHCP as static IP/values, e.g. dietpi-config adapter menu has this âcopyâ option.
- If the router has trouble with this, it might be possible to assign a static IP that is outside the DHCP range but within the same subnet. E.g. DHCP server assigns IPs 192.168.178.2 - 192.168.178.200, then assign 192.168.178.201 as static IP.
- Bad if a router has problems with both of the above, and even blocks NTP requests for clients then đ€.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [22 January 2020 22:19 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/15 "2020-01-22T22:19:54Z")
MichaIng
The whole topic is quite strange. I discovered it some weeks ago as I noticed that my Demo VMâs takes quite some time to reboot. I checked my RPi3B+ and RPi4B as well and found the same behavior. NTP time sync takes up to 40 sec to complete. However Iâm sure this was not the case in the past. Even more strange, the behavior seems to disappear after a while. I tried a lot of thinks in meantime but could not figure out what triggers NTP to take that long during boot. All my systems are using my Internet Router as NTP server (Gateway) now. However they are behaving different.
**Demo VM1**
```nohighlight
Jan 22 23:06:01 DietPiVM1 systemd[1]: Starting Network Time Synchronization...
Jan 22 23:06:01 DietPiVM1 systemd[1]: Started Network Time Synchronization.
Jan 22 23:06:09 DietPiVM1 systemd-timesyncd[550]: Synchronized to time server for the first time 192.168.0.1:123 (192.168.0.1).
Jan 22 23:06:09 DietPiVM1 systemd[1]: Stopping Network Time Synchronization...
Jan 22 23:06:09 DietPiVM1 systemd[1]: systemd-timesyncd.service: Succeeded.
Jan 22 23:06:09 DietPiVM1 systemd[1]: Stopped Network Time Synchronization.
root@DietPiVM1:~# systemd-analyze blame
2.691s dev-sda1.device
1.419s keyboard-setup.service
1.333s dietpi-preboot.service
1.231s mariadb.service
```
**RPi3B+**
```nohighlight
Jan 22 23:06:03 DietPi3 systemd[1]: Starting Network Time Synchronization...
Jan 22 23:06:04 DietPi3 systemd[1]: Started Network Time Synchronization.
Jan 22 23:06:44 DietPi3 systemd-timesyncd[448]: Synchronized to time server for the first time 192.168.0.1:123 (192.168.0.1).
Jan 22 23:06:45 DietPi3 systemd[1]: Stopping Network Time Synchronization...
Jan 22 23:06:45 DietPi3 systemd[1]: systemd-timesyncd.service: Succeeded.
Jan 22 23:06:45 DietPi3 systemd[1]: Stopped Network Time Synchronization.
root@DietPi3:~# systemd-analyze blame
34.163s dietpi-boot.service
2.019s mariadb.service
1.279s php7.3-fpm.service
1.266s dietpi-preboot.service
1.058s dev-mmcblk0p2.device
```
**RPi4B**
```nohighlight
Jan 22 23:04:51 DietPi4 systemd[1]: Starting Network Time Synchronization...
Jan 22 23:04:51 DietPi4 systemd[1]: Started Network Time Synchronization.
Jan 22 23:05:01 DietPi4 systemd-timesyncd[617]: Timed out waiting for reply from 192.168.0.1:123 (192.168.0.1).
Jan 22 23:05:43 DietPi4 systemd-timesyncd[617]: Synchronized to time server for the first time 192.168.0.1:123 (192.168.0.1).
Jan 22 23:05:43 DietPi4 systemd[1]: Stopping Network Time Synchronization...
Jan 22 23:05:43 DietPi4 systemd[1]: systemd-timesyncd.service: Succeeded.
Jan 22 23:05:43 DietPi4 systemd[1]: Stopped Network Time Synchronization.
root@DietPi4:~# systemd-analyze blame
43.091s dietpi-boot.service
1.214s dietpi-preboot.service
1.072s rpi-eeprom-update.service
872ms dev-mmcblk0p2.device
864ms wg-quick@wg0.service
```
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [23 January 2020 00:09 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/16 "2020-01-23T00:09:14Z")
Joulinar
Did you actually watch it taking that long? Because the timestamps of course change after time sync, usually into the future when last timestamp from last shutdown is restored via fake-hwclock. So it makes sense to boot with display and see DietPi-Run\_NTPD do its job, which does an info print for every second it waits for systemd-timesyncd.
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [23 January 2020 10:00 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/17 "2020-01-23T10:00:40Z")
MichaIng
I did a fresh reboot of all 3 devices before posting.
Attached a screen print from the RPi3B+
[](https://ibb.co/SrgZpgh)
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [24 January 2020 09:06 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/18 "2020-01-24T09:06:44Z")
Indeed that is long. It is with internal Ethernet adapter, static IP (DHCP disabled) and Gateway as NTP server?
Could you check journalctl about related kernel and systemd messages during boot?
---
### Author:  [@Joulinar](https://dietpi.com/forum/u/Joulinar)
#### Post date: [24 January 2020 10:38 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/19 "2020-01-24T10:38:36Z")
this is quite a strange topic. I was playing a little bit with STATIC and DHCP and honestly it doesnât matter. Sometimes itâs pritty fast on STATIC
```nohighlight
root@DietPi3:~# systemd-analyze blame
2.963s dietpi-boot.service
1.235s dietpi-preboot.service
1.098s dev-mmcblk0p2.device
```
and next time it hangs again
```nohighlight
root@DietPi3:~# systemd-analyze blame
43.698s dietpi-boot.service
1.295s dev-mmcblk0p2.device
1.226s dietpi-preboot.service
```
Interesting point, I have some timeout connecting to my local NTP server running on my Internet Router.
```nohighlight
Jan 24 11:28:36 DietPi3 systemd[1]: Started DietPi-RAMlog.
Jan 24 11:28:36 DietPi3 systemd[1]: Started DietPi-RAMdisk.
Jan 24 11:28:36 DietPi3 systemd[1]: Starting DietPi-PreBoot...
Jan 24 11:28:38 DietPi3 systemd[1]: Started DietPi-PreBoot.
Jan 24 11:28:38 DietPi3 systemd[1]: Reached target Network (Pre).
Jan 24 11:28:38 DietPi3 systemd[1]: Starting Raise network interfaces...
Jan 24 11:28:38 DietPi3 systemd[1]: Started ifup for eth0.
Jan 24 11:28:38 DietPi3 systemd[1]: Started Raise network interfaces.
Jan 24 11:28:38 DietPi3 systemd[1]: Reached target Network.
Jan 24 11:28:38 DietPi3 systemd[1]: Starting DietPi-Boot...
Jan 24 11:28:38 DietPi3 systemd[1]: Starting Permit User Sessions...
Jan 24 11:28:38 DietPi3 systemd[1]: Started Permit User Sessions.
Jan 24 11:28:38 DietPi3 sh[328]: eth0=eth0
Jan 24 11:28:38 DietPi3 systemd[1]: Starting Network Time Synchronization...
Jan 24 11:28:39 DietPi3 systemd[1]: Started Network Time Synchronization.
Jan 24 11:28:39 DietPi3 systemd[1]: Reached target System Time Synchronized.
Jan 24 11:28:49 DietPi3 systemd-timesyncd[486]: Timed out waiting for reply from 192.168.0.1:123 (192.168.0.1).
Jan 24 11:29:06 DietPi3 systemd[1]: systemd-fsckd.service: Succeeded.
Jan 24 11:29:29 DietPi3 systemd-timesyncd[486]: Synchronized to time server for the first time 192.168.0.1:123 (192.168.0.1).
Jan 24 11:29:29 DietPi3 systemd[1]: Stopping Network Time Synchronization...
Jan 24 11:29:29 DietPi3 systemd[1]: systemd-timesyncd.service: Succeeded.
Jan 24 11:29:29 DietPi3 systemd[1]: Stopped Network Time Synchronization.
Jan 24 11:29:29 DietPi3 systemd[1]: Started DietPi-Boot.
Jan 24 11:29:29 DietPi3 systemd[1]: Started DietPi-PostBoot.
Jan 24 11:29:29 DietPi3 systemd[1]: Started Getty on tty1.
```
---
### Author:  [@MichaIng](https://dietpi.com/forum/u/MichaIng)
#### Post date: [24 January 2020 11:07 UTC](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772/20 "2020-01-24T11:07:39Z")
Does the router serve logs about the NTP requests and/or newly connected devices? The question is how fast it âacceptâ requests for both, NTP requests and internet connections from newly connected devices.
The prior done network connecting check within dietpi-boot only checks for an applied default gateway, which in case of static IP should be done very quickly when the interfaces are brought up. The eth0=eth0 print comes from [ifup@eth0.service](mailto:ifup@eth0.service), indicating that this has fully finished. But that does not mean that router internally the device requests are handled immediately.
[Next page](https://dietpi.com/forum/t/dietpi-boot-service-taking-40-seconds-on-rpi3b-and-pinea64/3772.md?page=2)