I'm customizing a Raspbian Stretch Lite image to fit my needs. I'm quite fine with the results but now I would like to speed up the booting process because it takes so long to complete.

Here some outputs:

$ systemd-analyze 
Startup finished in 1.653s (kernel) + 1min 31.345s (userspace) = 1min 32.999s


$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

multi-user.target @1min 31.250s
└─getty.target @11.659s
  └─autologin@tty1.service @11.658s
    └─rc-local.service @8.212s +80ms
      └─network-online.target @8.196s
        └─network.target @8.165s
          └─networking.service @3.291s +4.871s
            └─local-fs.target @3.249s
              └─run-user-1000.mount @16.903s
                └─local-fs-pre.target @1.907s
                  └─keyboard-setup.service @1.062s +843ms
                    └─systemd-journald.socket @1.057s
                      └─-.mount @872ms
                        └─system.slice @1.022s
                          └─-.slice @872ms


$ systemd-analyze blame
          4.871s networking.service
          4.634s dhcpcd.service
          4.551s busybox-syslogd.service
          4.393s raspi-config.service
          3.304s plymouth-quit-wait.service
          3.289s plymouth-quit.service
          1.999s dev-mmcblk0p2.device
          1.883s nmbd.service
          1.336s lighttpd.service
           972ms smbd.service
           843ms keyboard-setup.service
           738ms systemd-logind.service
           685ms ssh.service

As far as I understand the networking applications take over 14 seconds (networking.service, dhcpcd.service, nmbd.service, smbd.service, lighttpd.service, ssh.service).


  1. about the networking applications, do you think the delays are acceptable or there is a way to improve them?
  2. what does the raspi-config service do? It says "switch to ondemand cpu governor". Might I safely disable it?
  3. why the playmouth service take over 6 seconds to quit? Is it normal?


As pointed out in the comments, I cannot rely on an always-powered solution. For several reasons the Raspberry Pi is turned on and off physically (connecting and detaching the power supply) and this behavior cannot be changed. I could agree there might are better ways but this is a project constraint and I'm just focusing on how to reduce the boot time.

  • 1
    1. Why do you care how long boot takes - what are you actually going to do with the 10s you might potentially save? 2. Why do you reboot - I only boot my Pi, on average, every 3 months, after some major change. – Milliways Oct 20 '17 at 11:28
  • 1. Because it's a controller machine that the end user starts on demand. The boot time is critical in some situations to gain the machine control as fast as possible. 2. Like above, the RPi is turned off every time it's not used, even dozen of times per day. – Mark Oct 20 '17 at 11:33
  • 2
    I am an engineer (now retired) with 50 years experience. Over they years I learned not to waste my time working on symptoms, and to analyse the real problem. In this case you may have a problem with response time - the obvious solution is NOT to shut down the Pi. From the boot time you are running a model A or Zero - they consume ~100mA when idle. – Milliways Oct 20 '17 at 11:42
  • Please, don't propose alternative I cannot afford. I'm just asking how to reduce the boot time. Any advice on this topic is welcome. I cannot avoiding to shutdown the Pi. – Mark Oct 20 '17 at 12:04
  • If the RPi is being turned off and on dozens of time per day and the boot time is so important, why not suspend it instead? – Mark Stosberg Oct 20 '17 at 12:07

Lets approach this problem another way : systemd allows starting units in parallel. You actually don't care when every unit is finished. What you care about is when your unit starts , and how much time all other units your unit depends on take to become ready.

Check which dependencies your unit/program has and make your unit dependent on them instead of multi-user.target. You can also use the After= directive directly to enforce this , if using the Requires= driective doesn't do this properly.

  • Actually I moved my application after network.target because I need it (but I don't need to be online). I think I cannot move it earlier... – Mark Oct 21 '17 at 7:08
  • For an application that expects networking to be up, I suggest you use network-online.target. Target network.target is reached before the network is available for use. – Chad Farmer Oct 26 '17 at 21:58

Is your boot time really 1 1/2 minutes?!?? Something is wrong here:

multi-user.target @1min 31.250s
└─getty.target @11.659s

This means getty (terminal based login) was ready after ~11.7s, then another minute and 20 seconds passes before "multi-user.target" is ready. Yet nothing in either summary appears to be a culprit -- the service that takes the longest is networking, at ~5s.

Can you observe anything if you plug a screen in and watch the boot? I believe 1.5 minutes is some kind of default that systemd uses to wait on a service to initialize, after which it gives up and cancels it. If you watch a console, this will be shown with red asterisks doing a sort of Knight Rider thing whilst other services tick up with green "Ok"s.

If that's actually not an issue (it may not be noticeable depending on the context of use, e.g., since everything else is done I believe you could log in remotely before that time is up) and your boot time is ~10-12s, then stop obsessing -- no model of Pi is particularly beefy, and that is a reasonable amount of time for it to boot a full fledged OS.

  • Well, actually it takes 22 seconds from power up to start my application (that I use to define my boot time). I'm not obsessed but I'm just trying to optimize something. I.e. how to move some services (lighttpd, smbd, etc...) after my application? – Mark Oct 21 '17 at 6:04
  • Yes, it would make more sense to look at how to get your application started sooner. Systemd works in parallel so outside of dependency chains you are not going to get any solid guarantees -- but of course you can use Before= and pick something from some dependency chain that is bound to happen early because of the things that are dependent on it. E.g., probably Requires=local-fs.target and Before=networking.service (even if you require networking, you should be able to set your app up to retry until it can connect). – goldilocks Oct 21 '17 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.