From 15b0fdd5a6908307b92b75652dd6269b76b1b017 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Fri, 12 Jul 2019 09:36:17 +0200 Subject: man: document that "systemd-analyze blame/critical-chain" is not useful to track down job latency Fixes: #12272 --- man/systemd-analyze.xml | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) (limited to 'man/systemd-analyze.xml') diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index 5dce2ae8fb..7112362ac5 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -178,7 +178,13 @@ multi-user.target reached after 47.820s in userspace initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame doesn't display results for services with Type=simple, because systemd considers such services to be started - immediately, hence no measurement of the initialization delays can be done. + immediately, hence no measurement of the initialization delays can be done. Also note that this command + only shows the time units took for starting up, it does not show how long unit jobs spent in the + execution queue. In particular it shows the time units spent in activating state, + which is not defined for units such as device units that transition directly from + inactive to active. This command hence gives an impression of the + performance of program code, but cannot accurately reflect latency introduced by waiting for + hardware and similar events. <command>Show which units took the most time during boot</command> @@ -202,7 +208,12 @@ multi-user.target reached after 47.820s in userspace UNITs or for the default target otherwise). 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. Note that the output might be misleading as the initialization of services might - depend on socket activation and because of the parallel execution of units. + depend on socket activation and because of the parallel execution of units. Also, similar to the + blame command, this only takes into account the time units spent in + activating state, and hence does not cover units that never went through an + activating state (such as device units that transition directly from + inactive to active). Moreover it does not show information on + jobs (and in particular not jobs that timed out). <command>systemd-analyze time</command> -- cgit v1.2.3