Skip to content

Raspberry Pi Boot Time Optimization with systemd

The safest way to make a Raspberry Pi boot faster is to measure the critical path, change one service at a time, and confirm that the required application is actually ready sooner. Do not begin by copying a large list of config.txt, kernel, or service-disable tweaks from another system.

Quick answer: Raspberry Pi 5 boot time

Record five cold boots with systemd-analyze time, critical-chain, and an application-ready timestamp before changing anything. NVMe, disabling an unused wait service, or reducing startup work may help, but only the median before/after result on the same Pi proves an improvement.

If the symptom is general slowness rather than startup delay, begin with the Raspberry Pi OS performance optimization guide. Memory pressure, failing storage, and thermal throttling need different measurements.

Quick workflow

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Overall userspace and kernel timing
systemd-analyze time

# Units ordered by activation time
systemd-analyze blame

# Dependencies that determined the critical path
systemd-analyze critical-chain

# Services that failed during this boot
systemctl --failed

# Boot warnings and errors
journalctl -b -p warning --no-pager

Use the results in this order:

  1. Define the event that means "ready" for your project.
  2. Record at least five cold boots before changing anything.
  3. Investigate units on critical-chain, not merely the longest line in blame.
  4. Disable or delay one confirmed-unused service.
  5. Reboot five times and compare the median.
  6. Restore the change if reliability or functionality regresses.

What counts as Raspberry Pi boot time?

systemd-analyze time separates firmware, loader, kernel, initrd, and userspace where those stages are available. It does not necessarily measure the moment your kiosk, API, camera, or network connection becomes usable.

For an appliance, choose an application-level target such as:

  • SSH accepts a connection.
  • A systemd service reports active.
  • An HTTP health endpoint returns 200.
  • A kiosk page is visible and interactive.
  • A GPIO output reaches its required state.

Measure both systemd startup and that real readiness event. Optimising the wrong endpoint can make a report look better without improving the product.

Create a repeatable baseline

Save the system identity and boot measurements after each test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
mkdir -p "$HOME/boot-bench"

{
  date --iso-8601=seconds
  uname -a
  cat /etc/os-release
  systemd-analyze time
  systemd-analyze critical-chain
  systemctl --failed
} | tee "$HOME/boot-bench/boot-$(date +%Y%m%d-%H%M%S).txt"

Keep these conditions constant:

Variable Record it because
Raspberry Pi model and RAM Firmware and hardware initialisation differ
Raspberry Pi OS release systemd units and desktop stack change
Storage device and filesystem SD, USB SSD, and NVMe latency differ
Power supply Undervoltage can distort results and cause failures
Connected USB/HAT hardware Device discovery may add delays
Network connection DHCP and online dependencies vary
Desktop or Lite image Graphical startup adds a different target

Check power and throttling history after each run:

1
vcgencmd get_throttled

A value other than 0x0 means a power, frequency-cap, or thermal condition is current or has occurred since boot. Fix that before treating the timing as a clean benchmark.

Read systemd-analyze correctly

systemd-analyze blame

blame lists how long units spent activating, but a slow unit may have run in parallel and contributed little to total boot time. Treat it as a clue, not a list of services to disable.

1
systemd-analyze blame --no-pager | head -30

systemd-analyze critical-chain

The critical chain shows ordering dependencies that held up the selected target:

1
2
3
systemd-analyze critical-chain
systemd-analyze critical-chain multi-user.target
systemd-analyze critical-chain graphical.target

The @ time shows when a unit became active; the + time shows how long it took to start.

Boot timeline plot

Generate an SVG for a visual comparison:

1
systemd-analyze plot > boot-before.svg

After a change, generate boot-after.svg and compare the critical path rather than the total number of enabled services.

Find the cause of a slow unit

For a unit named example.service, inspect its status, definition, dependencies, and current-boot logs:

1
2
3
4
systemctl status example.service
systemctl cat example.service
systemctl list-dependencies example.service
journalctl -b -u example.service --no-pager

Questions to answer before changing it:

  • Is the service required by the application?
  • Is it waiting for hardware, DNS, DHCP, storage, or another unit?
  • Does it fail and retry until a timeout?
  • Can the application start without waiting for it?
  • Is the unit enabled directly or pulled in by another target?

Fixing an error or timeout is generally more valuable than hiding the service.

Safe optimisation 1: disable a confirmed-unused service

Check why it is enabled and what depends on it:

1
2
systemctl is-enabled example.service
systemctl list-dependencies --reverse example.service

Disable it only when you understand its purpose:

1
2
sudo systemctl disable --now example.service
sudo reboot

Restore it with:

1
sudo systemctl enable --now example.service

Examples that may be unused on a specific appliance include Bluetooth support on an Ethernet-only server or a print service on a system that never prints. They are not universally safe to disable.

Safe optimisation 2: remove unnecessary network waiting

A headless service may be ordered after network-online.target even when it can bind locally and retry its outbound connection later. Inspect the chain first:

1
2
systemd-analyze critical-chain network-online.target
systemctl list-dependencies --reverse network-online.target

Do not simply disable the wait-online service if the application requires a configured address, mounted network storage, correct network time, or DNS during startup. Instead, make the application resilient where appropriate:

  • Start after network.target when only the network stack is needed.
  • Retry remote connections with bounded backoff.
  • Expose readiness separately from process startup.
  • Keep network-online.target for services that truly require it.

Safe optimisation 3: make your own service precise

Avoid broad dependencies such as After=network-online.target when they are not needed. A simple local application can use:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
[Unit]
Description=My Raspberry Pi application
After=local-fs.target

[Service]
Type=simple
ExecStart=/usr/local/bin/my-app
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

After changing a unit:

1
2
3
4
sudo systemctl daemon-reload
sudo systemctl enable my-app.service
sudo systemctl restart my-app.service
systemctl status my-app.service

Use Type=notify only when the application actually sends the systemd readiness notification. Choosing a service type that does not match process behaviour can add timeouts or report false readiness.

Safe optimisation 4: use Raspberry Pi OS Lite

For SSH servers, gateways, and embedded applications that do not need a local graphical session, starting with Raspberry Pi OS Lite usually removes more work than manually dismantling a desktop installation.

Before migrating:

  1. Export application configuration and data.
  2. Record installed packages and enabled units.
  3. Prepare a second storage device rather than overwriting the working one.
  4. Reproduce the service and health check.
  5. Compare measured readiness and memory usage.

Keep the original storage as a rollback until the Lite installation has passed soak testing.

Safe optimisation 5: investigate storage

Slow or failing storage often appears as filesystem, database, or service delays. Check kernel messages and device health where supported:

1
2
journalctl -b -k --no-pager | grep -Ei 'mmc|nvme|usb|reset|timeout|error'
findmnt -no SOURCE,FSTYPE,OPTIONS /

Compare SD, USB SSD, or NVMe with the same OS image and workload. Do not publish a single boot result; use multiple cold boots and report the median plus the range.

See the Raspberry Pi benchmark methodology for a reproducible test record.

Changes to avoid copying blindly

The following frequently appear in old fast-boot guides but can create data loss, missing hardware, or an unbootable system:

Tweak Risk
Skipping filesystem checks with a fastboot kernel argument Hides a recovery mechanism and may leave corruption untreated
Overclocking SD timing Can cause intermittent I/O errors or corruption
Removing rootwait May fail when root storage is not ready
Disabling Wi-Fi, Bluetooth, I2C, SPI, audio, or camera in bulk Breaks attached hardware and services
Disabling swap on memory-constrained systems Can turn slow startup into out-of-memory failure
Disabling IPv6 globally Can delay or break modern network applications
Masking system units without dependency analysis Makes recovery harder than a reversible disable
Editing /boot/firmware/cmdline.txt across multiple lines Raspberry Pi expects the kernel command line on one line

Visual options such as quiet, splash settings, or hiding console output may change what users see without reducing real application readiness.

Benchmark table template

Variant Boot 1 Boot 2 Boot 3 Boot 4 Boot 5 Median App ready Failures
Baseline
Change A
Change B

Document the exact command or unit change for every row. If two changes are combined, you cannot tell which one helped.

Recovery checklist

If a change prevents normal startup:

  1. Connect a display and keyboard, or mount the boot/root filesystem from another Linux computer.
  2. Remove the most recent kernel or firmware edit using its backup.
  3. Boot into a rescue or emergency target if available.
  4. Re-enable the last disabled unit.
  5. Inspect the previous boot with journalctl -b -1.

For a service change:

1
2
3
sudo systemctl unmask example.service
sudo systemctl enable example.service
sudo systemctl daemon-reload

Keep a known-good storage image for devices that must recover without network access.

FAQ

What is a normal Raspberry Pi boot time?

There is no single useful number. Model, firmware, storage, OS image, attached hardware, network, and the definition of "ready" all matter. Compare the same device against its own repeatable baseline.

Why is a service high in systemd-analyze blame but not in critical-chain?

It probably started in parallel with other work. Reducing its activation time may lower resource contention, but it may not shorten the overall critical path.

Can Raspberry Pi boot in under 10 seconds?

Some minimal, purpose-built systems can, but the number is meaningless without the measurement boundary and hardware details. Measure your application-ready event and preserve required functionality.

Should I disable NetworkManager-wait-online.service?

Only after checking reverse dependencies and confirming that no required service needs a fully configured network at startup. A better fix may be to remove an unnecessary dependency from your own service.

Does NVMe always boot faster than microSD?

Not always. Device initialisation, controller behaviour, filesystem, random I/O, and services all contribute. Measure both configurations on the same board and OS image.