Bug 750185

Summary:	RFE: systemd-analyze graph/blame should show devices being waited for
Product:	[Fedora] Fedora	Reporter:	Marcel Schaal <mail>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dtardon, herrold, johannbg, johannbg, lpoetter, metherid, mschmidt, plautrba, systemd-maint, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-27 12:56:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	784611

Description Marcel Schaal 2011-10-31 09:44:04 UTC

Hi,

I removed my second hard disk, which contains a swap partition mounted via /etc/fstab. Start-up was fine but took very long, hence I tried "systemd-analyze blame", but it didn't show any suspicious service:
[root@marcel etc]# systemd-analyze blame
  1192ms rsyslog.service
   927ms fedora-loadmodules.service
   862ms NetworkManager.service
   799ms udev-settle.service

[root@marcel etc]# systemd-analyze 
Start-up finished in 1200ms (kernel) + 2200ms (initramfs) + 92290ms (userspace) = 95691ms

But dmesg tells us what's wrong:
[    5.828762] systemd-tmpfiles[928]: Successfully loaded SELinux database in 12ms 437us, size on heap is 476K.
[   93.617504] systemd[1]: Job dev-disk-by\x2duuid-ef489dbb\x2d3bdc\x2d46ac\x2d87df\x2d0fe9cc4bfc41.device/start timed out.
[   93.617516] systemd[1]: Job dev-disk-by\x2duuid-ef489dbb\x2d3bdc\x2d46ac\x2d87df\x2d0fe9cc4bfc41.swap/start failed with result 'dependency'.
[   93.617523] systemd[1]: Job dev-disk-by\x2duuid-ef489dbb\x2d3bdc\x2d46ac\x2d87df\x2d0fe9cc4bfc41.device/start failed with result 'timeout'.

How reproducible:
always, also tried on F15 with another PC

Steps to Reproduce:
1. Add the following line to your /etc/fstab:
UUID=ef489dbb-3bdc-46ac-87df-0fe9cc4bfc41 swap                    swap    defaults        0 0
2. reboot
3. check output of systemd-analyze

Regards
Marcel

Comment 1 Fedora End Of Life 2013-01-16 17:41:46 UTC

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 2 David Tardon 2022-09-27 12:56:00 UTC

systemd-analyze blame/plot only include units whose activation has begun (property ActiveEnterTimestampMonotonic > 0). But that never happens for a device unit if the underlying device doesn't exist.

I'm not even sure this is a bug (or a missing feature). These tools are quite simple: they only show time a unit took to activate. Time spent waiting on the unit's dependencies is not taken into account. (Neither are the unit's dependencies, in fact.) Your best bet is to report this upstream (https://github.com/system/systemd) to get their (current) opinion on it. Maybe the tools should be extended. Maybe a new, more capable, tool should be created. (Or maybe such a tool does already exist outside of systemd and I just don't know about it.) But in any case, this is not a thing we can solve in Fedora.