How do I investigate a Linux server that takes too long to boot?
systemd-analyze reports boot timing from the operating system’s point of view. A long-running unit in blame output is not necessarily the reason the whole boot was slow, because units can start in parallel. Use the critical dependency chain and relevant logs to establish what delayed the required target.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. Read boot timing and the critical chain
These read-only checks help distinguish manager startup and unit ordering. Provider firmware or guest provisioning stages may not be fully represented by every reported timing.
systemd-analyze time
systemd-analyze critical-chainInterpret the chain for the intended target and identify dependencies that blocked progress.
2. Inspect candidate delays
Use the ranking as a starting point, then review a selected unit’s current-boot messages and configuration.
systemd-analyze blame
systemctl --failed --no-pagerA unit’s activation duration is not equivalent to exclusive boot delay. Failed or waiting mounts can also affect readiness.
Check the result
- The suspected delay is supported by dependency and journal evidence, and the relevant application becomes ready within the expected interval after a planned verification boot.
Troubleshooting
- Boot timing looks healthy but the website is still unavailable
- Application startup, database warm-up, network configuration or external dependencies may complete after the measured target.
- A service is slow but not on the critical path
- Optimising it may not reduce overall boot time. Focus on the dependency that actually blocks readiness.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.