Hide Forgot
Description of problem: [$ dmesg | grep -i cgconfig 37.162227] systemd[1]: cgconfig.service: control process exited, code=exited status=1 [ 37.171123] systemd[1]: Unit cgconfig.service entered failed state. $ sudo systemctl status cgconfig.service cgconfig.service - LSB: start and stop the WLM configuration Loaded: loaded (/etc/rc.d/init.d/cgconfig) Active: failed since Thu, 28 Apr 2011 15:43:32 -0400; 20min ago CGroup: name=systemd:/system/cgconfig.service Version-Release number of selected component (if applicable): systemd-25-1.fc15.x86_64 initscripts-9.30-2.fc15.x86_64 How reproducible: each system start Steps to Reproduce: 1. boot system 2. 3. Actual results: error msgs....however, don't notice any problems as a result Expected results: No systemd error msgs Additional info: Sorry...don't know if initscripts or systemd or something else causing the errors. Wondering if this is related to /run creation? I see the following in cgconfig: $CGCONFIGPARSER_BIN -l $CONFIG_FILE retval=$? if [ $retval -ne 0 ]; then log_failure_msg "Failed to parse " $CONFIG_FILE return 1 fi also: touch "$lockfile" retval=$? if [ $retval -ne 0 ]; then log_failure_msg "Failed to touch $lockfile" return 1
Hmmppff...I see initscripts-9.30-2.fc15.x86_64 installed after above error and no reboot. After reboot it does not re-occur. Will close after a few more reboots. Sorry for the noise.
Its back. Is this something to be concerned about? $ sudo systemctl status cgconfig.service cgconfig.service - LSB: start and stop the WLM configuration Loaded: loaded (/etc/rc.d/init.d/cgconfig) Active: failed since Sat, 30 Apr 2011 10:45:25 -0400; 55min ago CGroup: name=systemd:/system/cgconfig.service $ dmesg | grep -B 10 -i cgconfig.service [ 37.530436] mcelog.setup[1375]: read: No such device [ 37.605807] smartd[1373]: smartd 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build) [ 37.607818] smartd[1373]: Opened configuration file /etc/smartd.conf [ 37.614509] smartd[1373]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices [ 37.620593] smartd[1373]: Device: /dev/sda, type changed from 'scsi' to 'sat' [ 37.622664] smartd[1373]: Device: /dev/sda [SAT], opened [ 37.636530] smartd[1373]: Device: /dev/sda [SAT], found in smartd database. [ 37.666734] NetworkManager[1353]: <info> NetworkManager (version 0.8.998-4.git20110427.fc15) is starting... [ 37.669234] NetworkManager[1353]: <info> Read config file /etc/NetworkManager/NetworkManager.conf [ 37.842025] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 38.891398] systemd[1]: cgconfig.service: control process exited, code=exited status=1 [ 38.900221] systemd[1]: Unit cgconfig.service entered failed state.
Also getting this issue with a fresh Fedora 15 install from Install DVD with latest updates. The error message is exactly the same.
The issue seems to be related to cgconfigparser, which behaves odd if any controllers are already mounted when the command is run. It seems to unmount them and return an error. I assume that the intended behaviour is to unmount and then remount the controllers. Reproducible (for me at least). Run this commandline several times and see what happens to the mountpoints: $ /sbin/cgconfigparser -l /etc/cgconfig.conf Also, running $ systemctl start cgred.service multiple times gets the service in an active state with all the controllers mounted.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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