[ClusterLabs] [EXT] Systemd resources stopping issue

Windl, Ulrich u.windl at ukr.de
Fri Jan 30 13:42:11 UTC 2026


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 <users-bounces at clusterlabs.org> On Behalf Of Marek Pastierik
Sent: Wednesday, January 21, 2026 1:29 PM
To: users at clusterlabs.org
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20260130/0c574c59/attachment.htm>


More information about the Users mailing list