Bug 458885

Summary:	stop/restart xinetd and httpd failing
Product:	[Fedora] Fedora	Reporter:	ericm24x7
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	poelstra, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-08-13 19:22:32 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:

Description ericm24x7 2008-08-12 21:32:34 UTC

Description of problem:
While the service is stopped (service xinetd stop). Restarting (service xinetd restart) will fail due to sub-command executing improperly. Below is the output error:

Boot splash control client
USAGE: plymouth [--help]  [--debug]  [--newroot=<string>]  [--quit]  [--ping]  [--sysinit]  [--show-splash]  [--hide-splash]  [--ask-for-password]  [--update=<string>]  [--wait] [subcommand [options]...]

Same problem with httpd:
  service httpd stop
  service httpd restart

Version-Release number of selected component (if applicable):
initscripts.x86_64 8.80-1

How reproducible:
persistent

Steps to Reproduce:
1. service xinetd stop
2. service xinetd restart

Comment 1 John Poelstra 2008-08-13 16:20:48 UTC

I do not see this problem at all with latest rawhide updates (2008-08-13) running on i386. initsripts-8.80-1.i386

Is this a fresh rawhide install?

What else is happening on your system prior to running 
service xinetd stop
service xinetd restart

from the command line?

Comment 2 ericm24x7 2008-08-13 19:22:32 UTC

Somehow the "yum update" I performed through repo build I pulled out a couple of days ago created an unstable state on my system. I re-installed 10-Alpha again and did NOT see the problem as I stated above. Maybe it is just some other unstable and/or transient packages affecting xinetd,httpd init scripts.

Anyway, I will closed this for now.