Diagnose systemd boot delays and unit ordering with systemd-analyze (blame, critical-chain, verify)

Documented steps

1. Overall timing: `systemd-analyze` prints kernel/initrd/userspace split; `systemd-analyze blame --no-pager` lists units by time consumed (parallel — the sum exceeds wall clock).
2. The real serialized path: `systemd-analyze critical-chain` shows the dependency chain to the default target, with '+' = time the unit took and '@' = time it became active. Target a specific unit: `systemd-analyze critical-chain myapp.service`.
3. Lint units before deploying: `systemd-analyze verify /etc/systemd/system/myapp.service` catches unknown directives, missing executables, and ordering cycles (exit code non-zero on problems).
4. Ordering cycles at boot appear in the journal as `Found ordering cycle on a.service/start` followed by `Job b.service/start deleted to break ordering cycle` — one unit is arbitrarily dropped; search: `journalctl -b --grep 'ordering cycle'`.
5. Inspect dependencies: `systemctl list-dependencies myapp.service` (add --reverse for what depends on it, --after/--before for ordering edges). `systemctl show myapp -p After,Before,Wants,Requires` gives the raw lists.
6. Visualize: `systemd-analyze plot > boot.svg` renders a Gantt chart of unit activation; `systemd-analyze dot myapp.service | dot -Tsvg > deps.svg` graphs dependencies.
7. Common fixes: disable unneeded *-wait-online services, convert hard After= chains to socket activation, move slow oneshots out of the critical chain (remove Before=multi-user.target style ordering).