Created attachment 530790 [details] /var/log/messages Description of problem: There are some systemd and systemctl errors in /var/log/messages. Version-Release number of selected component (if applicable): systemd.i686 36-3.fc16 @koji-override-0/$releasever systemd-sysv.i686 36-3.fc16 @koji-override-0/$releasever systemd-units.i686 36-3.fc16 @koji-override-0/$releasever How reproducible: Boot F16 RC1. Steps to Reproduce: 1. as above 2. 3. Actual results: Systemd related errors. See attachment /var/log/messages. Expected results: No errors. Additional info:
> systemd[1]: Failed to read PID file /var/run/iscsid.pid after start. > The service might be broken. /etc/init.d/iscsid promised to create a PID file (it has a "# pidfile:" chkconfig header), but it actually failed to do that, or it did it too late in a racy way. The correct non-racy method is described at: http://0pointer.de/public/systemd-man/daemon.html The message is a warning and the service likely still works, but it should be fixed nevertheless. The initscript belongs to iscsi-initiator-utils. > systemd[1]: Failed to read PID file /var/run/fcoemon.pid after start. > The service might be broken. A similar bug in fcoe-utils. > systemctl[1021]: Failed to issue method call: No such file or directory This is just firstboot-graphical.service trying to disable a non-existent service in its ExecStartPost step. A bug in the firstboot package. I'll reassing this to iscsi-initiator-utils and open clone bugs for fcoe-utils and firstboot.
*** Bug 752362 has been marked as a duplicate of this bug. ***
service iscsid status Active: inactive (dead) since # only start if nodes are setup to startup automatically, root is iscsi, # or if iscsid is managing the sessions. grep -qrs "node.startup = automatic" /var/lib/iscsi/nodes so if iscsid doesn't started the msg is right .
In that case it would make sense to exit the initscript with a different exit code than 0. One of these LSB defined codes would do: 6: program is not configured 7: program is not running
(In reply to comment #4) > In that case it would make sense to exit the initscript with a different exit > code than 0. One of these LSB defined codes would do: > 6: program is not configured > 7: program is not running Not sure if this helped or not. I did this: diff --git a/iscsid.init b/iscsid.init index c208ccc..7dff612 100755 --- a/iscsid.init +++ b/iscsid.init @@ -82,7 +82,8 @@ start() { return $? fi - return 0 + # There are no targets configured to run. + exit 6 } stop() { And now I get (it used to report success): service iscsid start Starting iscsid (via systemctl): Job failed. See system logs and 'systemctl status' for details. [FAILED] but systemd still reports: Feb 1 18:09:36 madmax systemd[1]: PID file /var/run/iscsid.pid not readable (yet?) after start. Feb 1 18:09:36 madmax systemd[1]: Unit iscsid.service entered failed state. This error message about the PID is slightly different. I think the systemd message is incorrrect here though. It should not be reporting the PID message i this case because we already know that the service did not start correctly. So the patch might fix this problem: https://bugzilla.redhat.com/show_bug.cgi?id=786174 but you still get a error message in the logs. The other alt is to just remove that check in comment #3 and just always start iscsid. The iscsid script can then default to off for normal use and to on for root on iscsi use. The iscsidevs script will then do the right thing.
(In reply to comment #5) > I think the systemd message is incorrrect here though. > It should not be reporting the PID message in this case because > we already know that the service did not start correctly. Cloned as systemd bug 786806.
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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.