>>> Ken Gaillot <[email protected]> schrieb am 25.03.2019 um 20:03 in Nachricht <[email protected]>: > On Mon, 2019-03-25 at 10:42 -0700, Cole Miller wrote: >> Hi [email protected], >> >> 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 <[email protected]> > > _______________________________________________ > 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/
