[ClusterLabs] Apache doesn't start under corosync with systemd

[Jan Pokorný]

On 04/10/19 14:10 +0000, Reynolds, John F - San Mateo, CA - Contractor wrote:
> I've just upgraded a two-node active-passive cluster from SLES11 to
> SLES12.  This means that I've gone from /etc/init.d scripts to
> systemd services.
> 
> On the SLES11 server, this worked:
> 
>         <primitive id="ncoa_apache" class="ocf" provider="heartbeat" type="apache">
>           <instance_attributes id="ncoa_apache-instance_attributes">
>             <nvpair name="configfile" value="/etc/apache2/httpd.conf" id="ncoa_apache-instance_attributes-configfile"/>
>           </instance_attributes>
>           <operations>
>             <op name="monitor" interval="40s" timeout="60" id="ncoa_apache-monitor-40s"/>
>           </operations>
>         </primitive>
> 
> I had to tweak /etc/init.d/apache2 to make sure it only started on the active node, but that's OK.
> 
> On the SLES12 server, the resource is the same:
> 
>         <primitive id="ncoa_apache" class="ocf" provider="heartbeat" type="apache">
>           <instance_attributes id="ncoa_apache-instance_attributes">
>             <nvpair name="configfile" value="/etc/apache2/httpd.conf" id="ncoa_apache-instance_attributes-configfile"/>
>           </instance_attributes>
>           <operations>
>             <op name="monitor" interval="40s" timeout="60s" id="ncoa_apache-monitor-40s"/>
>           </operations>
>         </primitive>
> 
> and the cluster believes the resource is started:
> 
> 
> eagnmnmep19c1:/var/lib/pacemaker/cib # crm status
> Stack: corosync
> Current DC: eagnmnmep19c0 (version 1.1.16-4.8-77ea74d) - partition with quorum
> Last updated: Fri Oct  4 09:02:52 2019
> Last change: Thu Oct  3 10:55:03 2019 by root via crm_resource on eagnmnmep19c0
> 
> 2 nodes configured
> 16 resources configured
> 
> Online: [ eagnmnmep19c0 eagnmnmep19c1 ]
> 
> Full list of resources:
> 
> Resource Group: grp_ncoa
>       (edited out for brevity)
>      ncoa_a05shared     (ocf::heartbeat:Filesystem):    Started eagnmnmep19c1
>      IP_56.201.217.146  (ocf::heartbeat:IPaddr2):       Started eagnmnmep19c1
>      ncoa_apache        (ocf::heartbeat:apache):        Started eagnmnmep19c1
> 
> eagnmnmep19c1:/var/lib/pacemaker/cib #
> 
> 
> But the httpd daemons aren't started.  I can start them by hand, but
> that's not what I need.
> 
> I have gone through the ClusterLabs and SLES docs for setting up
> apache resources, and through this list's archive; haven't found my
> answer.   I'm missing something in corosync, apache, or systemd.
> Please advise.

I think you've accidentally arranged a trap for yourself to fall in.

What makes be believe so is that you've explicitly mentioned you've
modified /etc/init.d/apache2 explicitly.  In RPM driven ecosystem
(incl. SUSE), it means that on removal/upgrade of the respective
package, that file won't get removed.  This is what likely happened
on your major system upgrade.

Then, you can follow the logic in the agent itself, see in particular:
https://github.com/ClusterLabs/resource-agents/blob/v4.3.0/heartbeat/apache#L187-L188
It makes the agent assume it is not in systemd realms and switches
to use that provided initscript instead.  Apparently, that is _not_
supposed to necessarily work, since at that point, you have the
differing versions of httpd executables vs. the initscript (the former
is presumably newer than the latter), so any evolutionary differences
are not accounted for in the initscript itself (it's stale at that
point).

To resolve this, try simply renaming /etc/init.d/apache2 to something
else (or moving it somewhere else, simply to retain a backup of your
modifications), unmanage and manage the resource again, hopefully
systemd route to get httpd running will turn out well then.


-- 
Poki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20191007/09617d2c/attachment.sig>