Bug 1010068 - [RFE] Add --wait switch to cause glusterd to stay in the foreground until child services are started
[RFE] Add --wait switch to cause glusterd to stay in the foreground until chi...
Status: ASSIGNED
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
mainline
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: bugs@gluster.org
: RFE, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-19 16:53 EDT by Joe Julian
Modified: 2018-03-05 21:55 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Julian 2013-09-19 16:53:04 EDT
When deploying using automation tools, follow-up steps will fail as they follow too closely to glusterd daemonizing. This causes automated deployments to take multiple runs to create a GlusterFS cluster.

If we can add the ability to have daemonizing wait until everything is active and running this would solve this problem.
Comment 1 purpleidea 2013-09-19 17:01:47 EDT
Thanks Joe. here's the relevant commit and hack that I use to get around this :P
I don't mind though.

https://github.com/purpleidea/puppet-gluster/commit/17aff1a33a001cbb56735ff9f61a9bbcaa40cb04

Cheers

James
Comment 2 Louis Zuckerman 2014-08-06 16:32:07 EDT
Upstart, and probably systemd & other event driven init systems, would benefit from this, in cases where a client mounts from localhost during boot.  The service started event should not fire until the service is really ready to serve requests.  Currently if mounts are tried immediately after the service starts they will fail, because it's not really ready when it daemonizes.

Thanks.

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