Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 522789 - amtu initscript is not LSB compatible
Summary: amtu initscript is not LSB compatible
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: amtu
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Steve Grubb
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: InitScriptsProject 536888
TreeView+ depends on / blocked
 
Reported: 2009-09-11 13:05 UTC by Miroslav Vadkerti
Modified: 2009-11-11 17:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 536888 (view as bug list)
Environment:
Last Closed: 2009-09-14 13:51:36 UTC
Type: ---


Attachments (Terms of Use)

Description Miroslav Vadkerti 2009-09-11 13:05:45 UTC
Description of problem:
According to https://fedoraproject.org/wiki/FCNewInit/Initscripts there are several issues with amtu initscript:

ISSUE 1:
Mandatory option force-reload is not implemented

ISSUE 2:
Status after amtu is stopped returns 0, should be 3

ISSUE 3:
Status after amtu is not running but lock file exists returns 0, should be 2

Version-Release number of selected component (if applicable):
amtu-1.0.8-4.fc12

How reproducible:
always

Steps to Reproduce:
ISSUE 1:
1. service amtu force-reload
  
Actual results:
Usage: /etc/init.d/amtu {start|stop|status|restart|condrestart|reload}

Expected results:
force-reload option implemented

ISSUE 2:
1. service amtu stop
2. service amtu status; echo $?
  
Actual results:
0

Expected results:
3

ISSUE 3:
1. touch /var/run/amtu.pid
2. service amtu status; echo $?
  
Actual results:
0

Expected results:
2

Additional info:
available RHTS Sanity test for amtu initscripts:
/CoreOS/amtu/Sanity/init-scripts-LSB

amtu script also contains error - see 522708

Comment 1 Miroslav Vadkerti 2009-09-11 14:02:26 UTC
CORRECTION:

ISSUE 3:
Status after amtu is not running but pid file exists returns 0, should be 2

Comment 2 Miroslav Vadkerti 2009-09-11 14:42:10 UTC
Doh, please also ignore comment #1.

CORRECTION:

ISSUE 3:
Status after amtu is not running but pid file exists returns 0, should be 1

Comment 3 Steve Grubb 2009-09-11 15:29:52 UTC
ISSUE 1:
There is no concept of reloading a service that's not a service. Amtu is only doing a bootup check to ensure the system meets requirements. It would be similar in concept to firstboot, kudzu, or readahead. It should probably return 3.

ISSUE 2:
If the "service" is issued a stop command and at the end its not running, shouldn't that be a 0? I think its doing the right thing.

ISSUE 3:
Since amtu is not a "service", it does not make a pid file. You are introducing a bug by doing that. The correct answer would probably be 3 since status is unimplemented.

Comment 4 Miroslav Vadkerti 2009-09-11 16:33:49 UTC
Sorry for the 1 and 3 issues, to the issue 2:

According to https://fedoraproject.org/wiki/FCNewInit/Initscripts:
0 program is running or service is OK

3 program is not running 

But I don't really know what is correct in this situation, will check with David Kovalsky and reply to you.

Comment 5 Steve Grubb 2009-09-11 16:46:06 UTC
In unix, 0 means success. Failure is > 0. Since there can be many reasons to fail, there are many different failure codes.

Comment 6 Steve Grubb 2009-09-11 18:49:43 UTC
I built amtu-1.0.8-5 in rawhide to solve this problem. Please give it a test. Thanks.

Comment 7 Miroslav Vadkerti 2009-09-14 13:07:10 UTC
The package now looks ok, after discussion with David Kovalsky.

Comment 8 Steve Grubb 2009-09-14 13:51:36 UTC
Thanks for retesting and reporting the bug. Closing this report.


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