Here is an 'sudo systemd-analyze plot > ./1871148-vm-no-varlib-mount.svg' on a focal VM that reports the following critical-chain:
$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
Here is an 'sudo systemd-analyze plot > ./1871148- vm-no-varlib- mount.svg' on a focal VM that reports the following critical-chain:
$ sudo systemd-analyze critical-chain apparmor.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
apparmor.service +222ms user-122. mount @4.834s ─dev-disk- by\x2duuid- f5ea22a0\ x2de078\ x2d4d8e\ x2d9412\ x2d1fad2171a080 .swap @1.663s +24ms
└─dev- disk-by\ x2duuid- f5ea22a0\ x2de078\ x2d4d8e\ x2d9412\ x2d1fad2171a080 .device @1.662s
└─local-fs.target @2.562s
└─run-
└─swap.target @1.687s
└
Note that var.lib.mount is *not* listed in the critical chain. In the svg, we see:
zfs-load- module. service (3ms) cache.service (268ms) wait.service (235ms)
zfs-import-
zfs-import.target
...
var-lib.mount (156ms)
...
zfs-volume-
...
zfs-volumes.target
...
zfs-mount.service (66ms)
local-fs.target
apparmor.service (222ms)
...
Maybe everything is fine but critical-chain has a bug?