Bug 890540 - /etc/init.d/openstack-glance-api issues
Summary: /etc/init.d/openstack-glance-api issues
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Getting_Started_Guide
Version: 2.0 (Folsom)
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Stephen Gordon
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-27 16:19 UTC by Yaniv Kaul
Modified: 2016-04-27 01:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-07 17:30:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


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