Bug 750193 - Failed to read PID file /var/run/fcoemon.pid after start.
Summary: Failed to read PID file /var/run/fcoemon.pid after start.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fcoe-utils
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Šabata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-31 10:25 UTC by Michal Schmidt
Modified: 2011-11-25 02:07 UTC (History)
12 users (show)

Fixed In Version: fcoe-utils-1.0.20-5.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of: 749987
Environment:
Last Closed: 2011-11-25 02:07:29 UTC
Type: ---


Attachments (Terms of Use)

Description Michal Schmidt 2011-10-31 10:25:18 UTC
+++ This bug was initially created as a clone of Bug #749987 +++

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:

--- Additional comment from mschmidt@redhat.com on 2011-10-31 06:23:47 EDT ---

> 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.

Comment 1 Petr Šabata 2011-10-31 10:58:46 UTC
PID file was created and removed solely by the fcoe initsscript.  Since we don't use it anymore and systemd can live without it, I think just removing PIDFile from fcoe.service unit file should fix the issue.

Comment 2 Fedora Update System 2011-10-31 14:30:22 UTC
fcoe-utils-1.0.20-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/fcoe-utils-1.0.20-5.fc16

Comment 3 Fedora Update System 2011-11-01 01:25:44 UTC
Package fcoe-utils-1.0.20-5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing fcoe-utils-1.0.20-5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15173
then log in and leave karma (feedback).

Comment 4 Edgar Hoch 2011-11-21 14:52:34 UTC
After a fresh installation of Fedora 16 today /var/log/messages was filled with messages like this:

Nov 21 15:32:17 localhost fcoemon: error 111 Connection refused
Nov 21 15:32:17 localhost fcoemon: Failed to connect to lldpad

fcoemon was running, but lldpad was not running and has failed.


Now I installed fcoe-utils-1.0.20-5.fc16.x86_64 from updates-testing.
There is lldpad-0.9.43-5.fc16.x86_64 installed.

fcoe.service and lldpad.service is still started by default.

[root@localhost ~]# systemctl preset lldpad.service
[root@localhost ~]# systemctl preset fcoe.service
[root@localhost ~]# systemctl status lldpad.service
lldpad.service - Link Layer Discovery Protocol Agent Daemon.
	  Loaded: loaded (/lib/systemd/system/lldpad.service; enabled)
	  Active: active (running) since Mon, 21 Nov 2011 15:39:07 +0100; 5min ago
	Main PID: 1445 (lldpad)
	  CGroup: name=systemd:/system/lldpad.service
		  └ 1445 /usr/sbin/lldpad
[root@localhost ~]# systemctl status fcoe.service
fcoe.service - Open-FCoE Inititator.
	  Loaded: loaded (/lib/systemd/system/fcoe.service; enabled)
	  Active: active (running) since Mon, 21 Nov 2011 15:39:07 +0100; 5min ago
	Main PID: 1492 (fcoemon)
	  CGroup: name=systemd:/system/fcoe.service
		  └ 1492 /usr/sbin/fcoemon --syslog


Is it right that "systemctl preset ..." resets the service to the default state?
If so, both are still started on installation of the package, but should not?

Comment 5 Michal Schmidt 2011-11-21 15:18:45 UTC
(In reply to comment #4)
> Is it right that "systemctl preset ..." resets the service to the default
> state?

We do not take advantage of "systemctl preset" in Fedora yet. We don't ship any preset policy files and the packages' scriptlets never call the action.

Comment 6 Edgar Hoch 2011-11-21 15:30:43 UTC
(In reply to comment #5)
> > Is it right that "systemctl preset ..." resets the service to the default
> > state?
> 
> We do not take advantage of "systemctl preset" in Fedora yet. We don't ship any
> preset policy files and the packages' scriptlets never call the action.

Thanks for the information.

I have installed fcoe-utils-1.0.20-5.fc16 after a fresh install of Fedora 16.
Then fcoe.service was still enabled. In
https://admin.fedoraproject.org/updates/FEDORA-2011-15173
there is a line "Bugs Fixed"
701999 - Shouldn't start by default

This suggests me that after installing this update fcoe.service should be changed to disabled if the state was not modified explicitly by the user.

But how can I test it to leave karma?

Comment 7 Michal Schmidt 2011-11-21 16:33:08 UTC
(In reply to comment #6)
> This suggests me that after installing this update fcoe.service should be
> changed to disabled if the state was not modified explicitly by the user.

Doing that in an update would break the system for the users who need the service to be enabled and were happy when it originally shipped as such. These users did not have to modify the state explicitly.

The update affects only new installations of the package. To test it, remove the package first and then reinstall it.

Comment 8 Edgar Hoch 2011-11-21 17:01:53 UTC
Thanks for the advice!

I removed and reinstalled the package. Now fcoe.service is disabled after installation.

I have leaved karma on
https://admin.fedoraproject.org/updates/FEDORA-2011-15173


But another problem still exists: After
# systemctl start fcoe.service

/var/log/messages is filled with lines like this:

Nov 21 17:58:03 localhost fcoemon: error 111 Connection refused
Nov 21 17:58:03 localhost fcoemon: Failed to connect to lldpad

If fcoe requires lldpad, then should fcoe start lldpad?

Comment 9 Petr Šabata 2011-11-22 09:23:51 UTC
(In reply to comment #8)
> Thanks for the advice!
> 
> I removed and reinstalled the package. Now fcoe.service is disabled after
> installation.
> 
> I have leaved karma on
> https://admin.fedoraproject.org/updates/FEDORA-2011-15173

Thanks.

> But another problem still exists: After
> # systemctl start fcoe.service
> 
> /var/log/messages is filled with lines like this:
> 
> Nov 21 17:58:03 localhost fcoemon: error 111 Connection refused
> Nov 21 17:58:03 localhost fcoemon: Failed to connect to lldpad
> 
> If fcoe requires lldpad, then should fcoe start lldpad?

In theory, lldpad is not strictly required and current unit file states fcoe.service should start _after_ lldpad.service.

Most FCoE users are going to use LLDP agent as well so I suppose we could make fcoe.service require lldpad.service to avoid the log spam at least (I don't think silencing this or changing the log level to debug is a good idea here).

Those who wish to run fcoe.service without lldpad could adjust their unit file.

Would you file a new bug report for this?

Comment 10 Fedora Update System 2011-11-25 02:07:29 UTC
fcoe-utils-1.0.20-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.