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

Ken Gaillot kgaillot at redhat.com
Tue Mar 26 15:16:24 EDT 2019


On Tue, 2019-03-26 at 11:36 -0700, Cole Miller wrote:
> Hi,
> 
> Thank you very much Andrei, Ken and Ulrich for your input! 
> 
> I should have mentioned that I did start with trying apachectl
> graceful, but it fails to find the process because the httpd process
> is not being run via systemd.

Oh right, I forgot apachectl behaves differently if systemd is running.

I believe you can say "apachectl -k graceful" and it goes the
signalling route.

> 
> The explanation of why this capability is not present in the control
> script makes sense, configuration of httpd is outside the scope of
> the clustering software.
> 
> I will proceed with my workarounds that I have found so far. 
> 
> Thank you all again so much for your quick help.
> 
> Best regards, 
> Cole
> 
> > On Mar 26, 2019, at 12:02 AM, Ulrich Windl <
> > Ulrich.Windl at rz.uni-regensburg.de> wrote:
> > 
> > > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 25.03.2019 um
> > > > > 20:03 in
> > 
> > Nachricht
> > <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 ;-)
> > 
> > Regards,
> > Ulrich
> > 
> > > 
> > > > 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/ 
> > 
> > 
> > 
> > _______________________________________________
> > Manage your subscription:
> > https://lists.clusterlabs.org/mailman/listinfo/users
> > 
> > ClusterLabs home: https://www.clusterlabs.org/
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
-- 
Ken Gaillot <kgaillot at redhat.com>



More information about the Users mailing list