Bug 890540

Summary: /etc/init.d/openstack-glance-api issues
Product: Red Hat OpenStack Reporter: Yaniv Kaul <ykaul>
Component: doc-Getting_Started_GuideAssignee: Stephen Gordon <sgordon>
Status: CLOSED WONTFIX QA Contact: ecs-bugs
Severity: low Docs Contact:
Priority: low    
Version: 2.0 (Folsom)CC: breeler, jkt, sgordon
Target Milestone: ---Keywords: Documentation, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-07 17:30:54 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 Yaniv Kaul 2012-12-27 16:19:45 UTC
Description of problem:
1. 'start' appear to succeed, although it really didn't work:

[root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api start
Starting openstack-glance-api:                             [  OK  ]
[root@ykaul-os-horizon /(keystone_admin)]$ echo $?
0
[root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api status
openstack-glance-api dead but pid file exists

2. The above message is not useful (enough):
openstack-glance-api dead but pid file exists
should be something like:
openstack-glance-api dead but pid file exists ( /var/run/glance/glance-api.pid)

3. Removal of the pid file does not seem to suffice:
root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api status
openstack-glance-api dead but subsys locked

(note, the process was indeed dead).
The above message is not very helpful to diagnose the issue.
I assume it referred to the existence of /var/lock/subsys/openstack-glance-api


Version-Release number of selected component (if applicable):
openstack-glance-2012.2.1-1.el6ost.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Perry Myers 2013-01-04 00:03:24 UTC
(In reply to comment #0)
> Description of problem:
> 1. 'start' appear to succeed, although it really didn't work:
> 
> [root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api
> start
> Starting openstack-glance-api:                             [  OK  ]
> [root@ykaul-os-horizon /(keystone_admin)]$ echo $?
> 0
> [root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api
> status
> openstack-glance-api dead but pid file exists

This is not unusual for processes that may start properly and then fail a short time later due to some issue.  For example, if you start a service and it fails to contact the database the initial start operation will succeed (in that the daemon was successfully spawned) but later the daemon may exit (async to the start event) due to an error/misconfiguration.

So the above isn't indicative of a bug, it is expected behavior
 
> 2. The above message is not useful (enough):
> openstack-glance-api dead but pid file exists
> should be something like:
> openstack-glance-api dead but pid file exists (
> /var/run/glance/glance-api.pid)

I think the existing wording is pretty typical of init scripts
 
> 3. Removal of the pid file does not seem to suffice:
> root@ykaul-os-horizon /(keystone_admin)]$ /etc/init.d/openstack-glance-api
> status
> openstack-glance-api dead but subsys locked

Removal of the pid is not the correct way to correct this.  The way to clean up from a failed service is to issue a stop command first.  That will clean up the pid and return the status to stopped properly
 
> (note, the process was indeed dead).
> The above message is not very helpful to diagnose the issue.
> I assume it referred to the existence of
> /var/lock/subsys/openstack-glance-api

Yep

The use of the service stop command to correct the above issue is common among a lot of core linux services, so I don't think we need to work around this.  At best it's a documentation issue to say something like:

If you see this error message:
  a. Look at the log file to determine why the service failed
  b. run service stop to reset things
  c. fix the issue that caused the service to fail
  d. reissue the start command

I'm going to move this to the documentation component, since I think that is where this is best addressed

Comment 3 Stephen Gordon 2013-03-07 17:30:54 UTC
I'm closing this WONTFIX. I understand the complaint but I don't think a generic "how to troubleshoot linux services" (I'm assuming glance-api is really just an example here and that the same problem is potentially faced with other components) chapter fits with the RHOS documentation suite at this time given other more pressing gaps.