Bug 1025798 - quagga daemon pidfiles remain after daemons are stopped
quagga daemon pidfiles remain after daemons are stopped
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: quagga (Show other bugs)
rawhide
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-01 11:30 EDT by Michal Sekletar
Modified: 2014-12-08 11:14 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 842309
Environment:
Last Closed: 2014-12-08 11:14:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Sekletar 2013-11-01 11:30:33 EDT
+++ This bug was initially created as a clone of Bug #842309 +++

+++ This bug was initially created as a clone of Bug #508800 +++

Description of problem:
Quagga daemons (e.g. zebra, ospfd) write pidfiles under /var/run/quagga.  These pidfiles are not removed when the daemons are stopped.

Version-Release number of selected component (if applicable):
quagga-0.98.6-5.el5

How reproducible:
Always

Steps to Reproduce:
1. service zebra start
2. service zebra stop
  
Actual results:
The pidfile (/var/run/quagga/zebra.pid) remains after "stop".

Expected results:
The pidfile should be deleted upon stopping the service.

Additional info:
The killproc function in /etc/rc.d/init.d/functions is looking for /var/run/zebra.pid if no pidfile was explicitly passed with -p.

Could either pass the pidfile to killproc:

@@ -35,7 +35,7 @@
        ;;
   stop)
        echo -n $"Shutting down $prog: "
-       killproc zebra
+       killproc -p /var/run/quagga/zebra.pid zebra
        RETVAL=$?
        [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/zebra
        echo


... or configure quagga with pidfiles under /var/run.

--- Additional comment from lsmid@redhat.com on 2010-07-30 06:41:48 EDT ---

This bug is not scheduled for inclusion into RHEL 5.6. The bug will be rejected for RHEL 5.6 on Aug 6 unless it is escalated. Please note that RHEL 5.6 is resource constrained release and it is unlikely that Red Hat Product Management will accept any additional requests.

--- Additional comment from pm-rhel@redhat.com on 2010-08-09 14:24:33 EDT ---

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

--- Additional comment from pm-rhel@redhat.com on 2011-01-11 15:33:48 EST ---

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

--- Additional comment from pm-rhel@redhat.com on 2011-01-11 18:24:23 EST ---

This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

--- Additional comment from pm-rhel@redhat.com on 2011-05-31 09:26:21 EDT ---

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

--- Additional comment from pm-rhel@redhat.com on 2012-06-28 09:59:21 EDT ---

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release.  Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products.  This request is not yet committed for inclusion in
a release.

--- Additional comment from ovasik@redhat.com on 2012-06-28 11:41:50 EDT ---

dev_ack+ for 5.9

--- Additional comment from azelinka@redhat.com on 2012-07-10 12:45:17 EDT ---

5.9 qa_ack+

--- Additional comment from atkac@redhat.com on 2012-07-12 10:28:23 EDT ---

Fixed in quagga-0.98.6-9.el5

http://bulk-mail.corp.redhat.com/archives/cvs-commits-list/2012-July/msg02817.html

--- Additional comment from errata-xmlrpc@redhat.com on 2012-07-12 10:34:00 EDT ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2012:13381-01
http://errata.devel.redhat.com/errata/show/13381

--- Additional comment from errata-xmlrpc@redhat.com on 2012-07-19 12:51:02 EDT ---

Bug report changed from ON_QA to VERIFIED status by the Errata System: 
Advisory RHBA-2012:13381-01: 
http://errata.devel.redhat.com/errata/stateview/13381

Reproducer:
1. service zebra start
2. service zebra stop
3. check that /var/run/quagga/zebra.pid doesn't exists

Fixed:
After `service zebra stop` file doesn't exists

--- Additional comment from Ondrej Hudlicky on 2012-11-12 05:15:02 EST ---

This issue was reported by Quality Engineering during RHEL7 Alpha campaign. If the bug is fixed in the latest RHEL7 tree, change the status to MODIFIED. For unresolved issues could you please deliver the fix by development freeze January 4th 2013? Otherwise provide ETA with short justification.

--- Additional comment from Michal Sekletar on 2013-07-31 09:09:39 EDT ---

There are two possible approaches here, either I could patch all daemons in quagga not to use pidfiles at all. systemd will always know the main pid of the service. Although there might be scripts out there using those pidfile from whatever reasons. Second approach would be, adding ExecStopPost= action to unit files where we could call rm command on pidfile.

I would say that second option is easier to implement and more sensible choice considering backward compatibility.

--- Additional comment from John Skeoch on 2013-10-31 21:37:37 EDT ---

User asersen@redhat.com's account has been closed

--- Additional comment from Michal Sekletar on 2013-11-01 11:04:46 EDT ---

systemd now removes pidfiles automatically when they are referenced in a service file. I will add PIDFile= option to all quagga service files.
Comment 1 Michal Sekletar 2013-12-02 11:42:08 EST
pidfiles are created by quagga daemons, but not referenced in systemd configuration. systemd nowadays removes pidfile once service is stopped. We should add PIDFile= option to [Service] section to service file for each daemon.
Comment 2 Michal Sekletar 2014-12-08 11:14:46 EST
Already fixed in rawhide.

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