[ClusterLabs] Antw: Re: Apache graceful restart not supported by heartbeat apache control script

Ulrich Windl Ulrich.Windl at rz.uni-regensburg.de
Tue Mar 26 03:02:23 EDT 2019

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 25.03.2019 um 20:03 in
<a227e94c55459af8c04ae9fe6f11438fdd6ddd32.camel at redhat.com>:
> On Mon, 2019-03-25 at 10:42 -0700, Cole Miller wrote:
>> Hi users at clusterlabs.org,
>> My current project at work is a two node cluster running apache and
>> virtual IPs on CentOS 7. I found in my testing that apache when run
>> by corosync does not have a reload or graceful restart. Before the
>> cluster, when apache was a single instance, I previously used
>> graceful restart to be able to add configurations with out affecting
>> current users of the system.
>> Initially, I tried adding the capability myself as a resource action
>> in the pcs configuration, I was able to add the action, but it would
>> have no effect when run. Digging deeper, I eventually found the
>> apache control script at /usr/lib/ocf/resource.d/heartbeat/apache and
>> was able to see that there are no commands available for a graceful
>> restart, only graceful stop. 
>> Currently, I have found two ways of getting around this limitation.
>> The first is “/bin/kill -USR1 `cat /var/run/httpd.pid`", and the
>> second is "/bin/test -f /var/run/httpd.pid && /usr/sbin/httpd -f
>> /etc/httpd/conf/httpd.conf -c "PidFile /var/run/httpd.pid" -k
>> graceful”. Both seem to work with out adversely affecting corosync.
> Hi,
> apachectl (apache2ctl on some distros) is an easier interface, i.e.
> "apachectl graceful"
>> My primary question is; what is the reason that graceful restart is
>> not supported by the heartbeat apache control script? It seems like a
>> pretty common usage of apache, so it seems a strange omission from
>> the script. I am concerned that I’m trying to work against the grain
>> since it is absent from the script.
> Like an init script, an OCF script is mainly intended for the system
> (the cluster in this case) to bring a service up or down, and then
> secondarily as a user interface for doing such actions. The cluster
> won't ever need or use a graceful restart command, so there hasn't been
> a demand for an OCF interface to it.

But there is a "reload" operation defined for OCF RA agents.

> I would just use apachectl for reloads and graceful restarts. Neither
> should affect pacemaker's monitoring (as long as they succeed). (By
> contrast, you shouldn't use apachectl to do a full start or stop if
> apache is being controlled by the cluster, because the cluster will see
> that as a failure.)

On gracefule restart: IMHO the RA could always try to do a graceful restart,
and only after some timeout had expired, it should switch to an immediate stop
of apache. You might compare it to the Xen RA: It always tried to shut down VMs
cleanly; only after a timeout expired the VMs are terminated the hard way.

> A side note: there is a "reload" action supported by some OCF agents,
> but its use is muddled in pacemaker right now. There is an effort to
> clear that up, after which we will likely implement a user interface
> for natively reloading a service. It would make sense for the apache
> agent to use a graceful restart for that action. So, in the longer
> term, there might be a way to do what you want via cluster tools.

Seems we agree on that ;-)


>> My second question is; are the two work arounds presented above safe
>> for use with corosync/heartbeat/pcs? Is one preferable to the other?
>> If neither are safe, how would you recommend being able to update
>> apache configurations with no downtime?
>> I am new to this list and could not find a way to search the
>> archives, so if this question has already been answered, could you
>> point me to the search area and to the answer as well?
>> Thank you in advance for your advice and recommendations.
>> -Cole
> -- 
> Ken Gaillot <kgaillot at redhat.com>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> ClusterLabs home: https://www.clusterlabs.org/ 

More information about the Users mailing list