Bug 826682

Summary:	Invalid expect stanza causes init script to become unusable until reboot
Product:	Red Hat Enterprise Linux 6	Reporter:	James B. Byrne <byrnejb>
Component:	upstart	Assignee:	Lukáš Nykrýn <lnykryn>
Status:	CLOSED CANTFIX	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.2	CC:	prc
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-13 11:35:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James B. Byrne 2012-05-30 18:29:01 UTC

Description of problem:
If an upstart init.conf script contains an invalid expect stanza then the ability to stop, reload or otherwise manage it is disabled until the system is rebooted

Version-Release number of selected component (if applicable):
upstart.x86_64-0.6.5-10.el6

How reproducible:
Create an /etc/init/script.conf file that runs a daemonizing process without including the expect stanza.  Use initctl reload-configuration and then initctl start script.

Steps to Reproduce:
1.  Create script missing expect stanza
2.  initctl reload-configuration
3.  initctl start script -> hangs
4.  ctrl-c
3.  initctl stop script
  
Actual results:
initctl: Job has already been stopped: local_ssh_imap_proxy

initctl start local_ssh_imap_proxy
 #hangs

ctrl-c

initctl status local_ssh_imap_proxy
local_ssh_imap_proxy start/killed, process 30107


Expected results:
'initcrtl stop script' should actually stop the script job and also clear internal references to stopped job.

Additional info:

This has been an issue with upstream for more than two years.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745

The real problem is that once a script gets trapped like this then the only remedies available are either to rename the script or to reboot the system.  This is a problematic situation as in most cases neither solution is very attractive from a system administration point of view.

Comment 3 Lukáš Nykrýn 2012-05-31 08:13:36 UTC

According to upstream discussion 
https://bugs.launchpad.net/upstart/+bug/406397 
https://bugs.launchpad.net/upstart/+bug/530779
this is quite hard to fix and it will probably need to rewrite whole fork following mechanism.

Comment 4 RHEL Program Management 2012-07-10 08:26:39 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 RHEL Program Management 2012-07-11 01:54:04 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 6 RHEL Program Management 2012-09-07 05:33:39 UTC

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 unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 7 James B. Byrne 2012-09-07 13:02:28 UTC

I would suggest then that this product should be reconsidered as 'experimental' and removed from RHEL until such time as the matter is resolved.  Requiring a reboot on an enterprise server simply to clean up after a rather trivial scripting error is not going to impress a lot of people.

Comment 8 Lukáš Nykrýn 2015-10-13 11:35:41 UTC

This is known issue of upstart design and basically can't be fixed. Systemd in rhel7 solves this.