RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 594767 - init script LSB is not compliant
Summary: init script LSB is not compliant
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openswan
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Avesh Agarwal
QA Contact: Aleš Mareček
URL:
Whiteboard:
Depends On:
Blocks: 633349
TreeView+ depends on / blocked
 
Reported: 2010-05-21 14:35 UTC by Aleš Mareček
Modified: 2010-11-11 14:52 UTC (History)
3 users (show)

Fixed In Version: openswan-2_6_24-4_el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 14:52:09 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Aleš Mareček 2010-05-21 14:35:22 UTC 
Description of problem:
According to https://fedoraproject.org/wiki/Packaging/SysVInitScript is init script of openswan not compliant. After killing started daemon status returns 2. Value: 1 is expected.

:: [   PASS   ] :: Running 'service ipsec start'
:: [   PASS   ] :: Running 'kill -n 9 8508'
:: [   FAIL   ] :: Running 'service ipsec status' (Expected 1, got 2)
:: [   LOG    ] :: Duration: 1s


Version-Release number of selected component (if applicable):
openswan-2.6.24-3.el6

How reproducible:
always

Steps to Reproduce:
1. service ipsec start
2. killall pluto
3. service ipsec status; echo $?
  
Actual results:
Exit code of status is 2

Expected results:
Exit code of status should be 1

Additional info:
Comment 1 Avesh Agarwal 2010-06-07 18:08:23 UTC 
According to https://fedoraproject.org/wiki/Packaging/SysVInitScript, some of the "status" outputs are:


0:	program is running or service is OK
1:	program is dead and /var/run pid file exists
2:	program is dead and /var/lock lock file exists
3:	program is not running

That means if "program is dead and /var/lock lock file exists", status should be "2" . That is what I get when we do "killall pluto", and "service ipsec status; echo $?", so wondering what is wrong?
Comment 2 Avesh Agarwal 2010-06-07 18:20:37 UTC 
Specifically, here is the output I get, If I give following commands:

1. service ipsec start
2. killall pluto
3. service ipsec status; echo $?


Output is:

IPsec stopped
but...
has subsystem lock (/var/lock/subsys/ipsec)!
2
Comment 3 Aleš Mareček 2010-06-08 07:35:12 UTC 
Sure, but as we are going to clean all init scripts, we should have them all with same behaviour.
When you kill pluto pidfile and lockfile exist. Now you have two choices to return (after status): 1 and 2 because both files exist. Correct behaviour is: at first you should check if pidfile exists, then lockfile.
From point of functionality view are both values correct but from point of correct initscript view thats a bug.
Comment 4 Avesh Agarwal 2010-06-08 14:29:27 UTC 
(In reply to comment #3)
> Sure, but as we are going to clean all init scripts, we should have them all
> with same behaviour.
> When you kill pluto pidfile and lockfile exist. Now you have two choices to
> return (after status): 1 and 2 because both files exist. 

Exactly, I had the same doubt in mind.

Correct behaviour is:
> at first you should check if pidfile exists, then lockfile.
> From point of functionality view are both values correct but from point of
> correct initscript view thats a bug.

If that is the right thing to be LSB compliant, I will fix it in next release.

Thanks
Avesh
Comment 6 releng-rhel@redhat.com 2010-11-11 14:52:09 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.