
find out what's slowing your linux boot
systemd-analyze blame | headthat painfully slow boot isn't just "old computer" syndrome
you hit power, you wait, you make coffee, you come back and it's still loading. most people just assume the machine is dying. sometimes it is. but a lot of the time it's one or two services quietly hogging the boot process every single time, and you'd never know unless you asked systemd directly. good news: it'll tell you exactly what's slow if you just ask.
the command
systemd-analyze blame | head
run that in a terminal on any linux box using systemd (which is most modern distros, ubuntu, fedora, debian, arch, etc). you'll get a list of every service that ran during boot, sorted from slowest to fastest, showing exactly how long each one took to start.
systemd-analyze is the built in diagnostic tool for systemd, the init system that boots your linux machine and manages services in the background. blame is the subcommand that specifically reports startup timing per unit. piping it to head just trims the output to the top of the list, since that's where the slowest offenders live and you don't need to scroll through 200 lines of stuff that started in 4 milliseconds.
reading the output without panicking
the output looks something like a duration followed by a service name, for example something like 8.912s NetworkManager-wait-online.service. that number is how long that specific unit took before it finished initializing during boot. anything in the tens of seconds range is worth a look. anything under half a second is normal noise and not your problem.
common repeat offenders: network wait services that sit there stalling until they get a connection, disk mount units waiting on slow or failing drives, snap or flatpak related services, printer spoolers nobody uses, and third party daemons that got installed once and never cleaned up.
going deeper if one service looks suspicious
blame gives you the list, but if you want the full picture of how boot time is structured, not just individual services, run:
systemd-analyze critical-chain
this shows the actual chain of dependencies, meaning which services had to wait on other services before they could even start. sometimes the slow part isn't the service itself, it's something upstream blocking it. this is how you catch a dependency problem instead of just blaming the wrong thing.
if you want to check what a specific service is actually doing before you touch it, use:
systemctl status servicename.service
this tells you if it's active, what it's for, and recent log lines, so you're not disabling something blind.
why this matters beyond just speed
a slow boot isn't only annoying, it's also a decent signal for stuff worth auditing. services you don't recognize, daemons installed by software you uninstalled months ago, or something phoning out to check for updates on every single startup are all things that show up here. this is also a quiet way to spot leftover software from an old vpn client, a trial security tool, or a program you forgot existed that's still running with permissions every time your machine turns on. slow boot times are sometimes just the visible symptom of stuff sitting on your system that you never actually cleaned up.
the takeaway
your machine will straight up tell you what's slowing it down, you just have to ask. run systemd-analyze blame | head, note anything that stands out, cross reference it with systemctl status before disabling anything, and if a service is safe to turn off you can disable it with systemctl disable servicename.service. don't mass disable things you don't understand, that's how you break networking or graphics on next boot. the goal here isn't to nuke everything, it's to know what's actually running on your own system, why it's there, and whether it still needs to be. that's the whole game in defense, visibility first, action second.