Bug 632037

Summary: cpuspeed service needs to be manually started after booting.
Product: [Fedora] Fedora Reporter: Gene Snider <genes1122>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-09 22:46:55 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:
Attachments:
Description Flags
Contents of /var/log/messages for most recent boot with systemd-9-3.fc14 none

Description Gene Snider 2010-09-09 00:43:13 UTC 
Description of problem:
The cpuspeed service isn't running after booting.  The only relevant lines in /var/log/messages are:
Sep  8 17:00:54 Mobile-PC cpuspeed: Enabling ondemand cpu frequency scaling governor
Sep  8 17:05:44 Mobile-PC cpuspeed: Disabling ondemand cpu frequency scaling governor
Sep  8 17:06:46 Mobile-PC kernel: init[1]: Walked on cycle path to cpuspeed.service/start

The service can be started by "sudo systemctl start cpuspeed.service".  This problem didn't exist on version 8.  Oddly, my system controlled wifi successfully starts at boot, unlike bruno who commented in bodhi.  

Version-Release number of selected component (if applicable):
9-3.fc14

How reproducible:
Easily.

Steps to Reproduce:
1. Update to systemd-9-3.fc14.
2. Reboot.
3.
  
Actual results:
The cpuspeed service isn't running.

Expected results:
It should be running.

Additional info:
Comment 1 Michal Schmidt 2010-09-09 09:02:36 UTC 
> Sep  8 17:06:46 Mobile-PC kernel: init[1]: Walked on cycle path to
> cpuspeed.service/start

Please attach the full log. We need to see what the full cycle is about.
Comment 2 Gene Snider 2010-09-09 18:56:33 UTC 
Created attachment 446346 [details]
Contents of /var/log/messages for most recent boot with systemd-9-3.fc14
Comment 3 Michal Schmidt 2010-09-09 22:15:26 UTC 
The log shows ondemand frequency scaling was enabled.

But there are dep cycles indeed.

init[1]: Found ordering cycle on haldaemon.service/start
init[1]: Walked on cycle path to irqbalance.service/start
init[1]: Walked on cycle path to restorecond.service/start
init[1]: Walked on cycle path to jexec.service/start
init[1]: Walked on cycle path to haldaemon.service/start
init[1]: Breaking ordering cycle by deleting job haldaemon.service/start
init[1]: Found ordering cycle on haldaemon.service/start
init[1]: Walked on cycle path to cpuspeed.service/start
init[1]: Walked on cycle path to restorecond.service/start
init[1]: Walked on cycle path to jexec.service/start
init[1]: Walked on cycle path to haldaemon.service/start
init[1]: Breaking ordering cycle by deleting job haldaemon.service/start
init[1]: Found ordering cycle on haldaemon.service/start
init[1]: Walked on cycle path to restorecond.service/start
init[1]: Walked on cycle path to jexec.service/start
init[1]: Walked on cycle path to haldaemon.service/start
init[1]: Breaking ordering cycle by deleting job haldaemon.service/start
init[1]: Found ordering cycle on haldaemon.service/start
init[1]: Walked on cycle path to jexec.service/start
init[1]: Walked on cycle path to haldaemon.service/start
init[1]: Breaking ordering cycle by deleting job haldaemon.service/start

Looks related to bug 631620.
Comment 4 Gene Snider 2010-09-09 22:28:39 UTC 
Yes, it was enabled, but that start was my manual systemctl after logging in.

Gene
Comment 5 Michal Schmidt 2010-09-09 22:46:55 UTC 
Hm, I see.

That makes the symptoms even more similar to bug 631620 - a dependency loop (involving haldaemon) is detected, the cycle is claimed to be broken by removing a service and a different service from the loop is removed.

*** This bug has been marked as a duplicate of bug 631620 ***