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
  └─[email protected] @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, 2017 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, 2017 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, 2017 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, 2017 at 12:04
  • 1
    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? Oct 20, 2017 at 12:07

3 Answers 3


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, 2017 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. Oct 26, 2017 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, 2017 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, 2017 at 11:33

I also find that a usb stick with exactly the same OS as the sd card slows down boot up time a lot and also once booted it runs extremely slow,tons and tons of latency so much so that the machine seems unresponsive

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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