Bug 522789

Summary:	amtu initscript is not LSB compatible
Product:	[Fedora] Fedora	Reporter:	Miroslav Vadkerti <mvadkert>
Component:	amtu	Assignee:	Steve Grubb <sgrubb>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	sgrubb
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	536888 (view as bug list)		Environment:
Last Closed:	2009-09-14 13:51:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	521669, 536888

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.