pacemaker-configuration is looking similar for both resources. But nginx service-type should be 'forking' while while service-type of 'puppetserver' is simple. Would've guessed it shouldn't make a difference here but maybe still worth while checking if this is the crucial difference.
Regards, Klaus On Fri, Jan 30, 2026 at 2:42 PM Windl, Ulrich <[email protected]> wrote: > Hi! > > > > I’d suggest two things: > > 1. Check the status using the systemctl status for the units and check > the RA’s monitor operation > 2. Provide cluster status output when the state looks bad (I’m using > “crm_mon -1Arfj”, but your preference may be different) > > > > Kind regards, > > Ulrich Windl > > > > *From:* Users <[email protected]> *On Behalf Of *Marek > Pastierik > *Sent:* Wednesday, January 21, 2026 1:29 PM > *To:* [email protected] > *Subject:* [EXT] [ClusterLabs] Systemd resources stopping issue > > > > Dear ClusterLabs team, > > I would like to ask for clarification regarding Pacemaker behavior with > systemd services. > > I am running *Pacemaker 2.1.10-2.el9* on a *3-node cluster* and currently > have *8 cluster resources*, two of which are systemd-based services: > *nginx.service* and *puppetserver.service*. > Both of these services are intended to run on only one node, but I am > testing whether Pacemaker will stop them if I manually start them on a > second node. > > I am seeing different behavior for two very similarly defined primitives. > > Specifically, *nginx.service* is actively being stopped by Pacemaker on > nodes where it should not be running, while *puppetserver.service* is > not, even though I would expect the same behavior. > > For nginx, I can see the following message in pacemaker-controld logs: > > pacemaker-controld[520998]: notice: Requesting local execution of stop > operation for nginx_service on X.Y.Z > > For puppetserver, I do not see a corresponding stop operation being > requested. > > The primitive definitions are: > > <primitive id="nginx_service" class="systemd" type="nginx.service"> > > <operations> > > <op name="monitor" interval="10s" role="Started" > > id="nginx_service-monitor-interval-10s"/> > > <op name="monitor" interval="11s" role="Stopped" > > id="nginx_service-monitor-interval-11s"/> > > <op name="start" interval="0s" > > id="nginx_service-start-interval-0s"/> > > <op name="stop" interval="0s" > > id="nginx_service-stop-interval-0s"/> > > </operations> > > <meta_attributes id="nginx_service-meta_attributes"/> > > </primitive> > > > > <primitive id="puppetserver_service" class="systemd" > type="puppetserver.service"> > > <operations> > > <op name="monitor" interval="10s" role="Started" > > id="puppetserver_service-monitor-interval-10s"/> > > <op name="monitor" interval="30s" role="Stopped" timeout="30s" > > id="puppetserver_service-monitor-interval-11s"/> > > <op name="start" interval="0s" > > id="puppetserver_service-start-interval-0s"/> > > <op name="stop" interval="0s" > > id="puppetserver_service-stop-interval-0s"/> > > </operations> > > <meta_attributes id="puppetserver_service-meta_attributes"/> > > </primitive> > > Could someone please explain why Pacemaker requests a local stop operation > for nginx.service, but not for puppetserver.service? > Is this related to differences in monitor intervals, systemd unit > behavior, or Pacemaker’s internal state handling? > > Thank you in advance for any insight. > > Best regards, > Marek Pastierik > _______________________________________________ > 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/
