<div dir="ltr"><p style="color:rgb(0,0,0)">Dear ClusterLabs team,</p><p style="color:rgb(0,0,0)">I would like to ask for clarification regarding Pacemaker behavior with systemd services.</p><p style="color:rgb(0,0,0)">I am running<span class="gmail-Apple-converted-space"> </span><strong>Pacemaker 2.1.10-2.el9</strong><span class="gmail-Apple-converted-space"> </span>on a<span class="gmail-Apple-converted-space"> </span><strong>3-node cluster</strong><span class="gmail-Apple-converted-space"> </span>and currently have<span class="gmail-Apple-converted-space"> </span><strong>8 cluster resources</strong>, two of which are systemd-based services:<span class="gmail-Apple-converted-space"> </span><strong>nginx.service</strong><span class="gmail-Apple-converted-space"> </span>and<span class="gmail-Apple-converted-space"> </span><strong>puppetserver.service</strong>.<br>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.</p><p style="color:rgb(0,0,0)">I am seeing different behavior for two very similarly defined primitives.</p><p style="color:rgb(0,0,0)">Specifically,<span class="gmail-Apple-converted-space"> </span><strong>nginx.service</strong><span class="gmail-Apple-converted-space"> </span>is actively being stopped by Pacemaker on nodes where it should not be running, while<span class="gmail-Apple-converted-space"> </span><strong>puppetserver.service</strong><span class="gmail-Apple-converted-space"> </span>is not, even though I would expect the same behavior.</p><p style="color:rgb(0,0,0)">For nginx, I can see the following message in<span class="gmail-Apple-converted-space"> </span><code>pacemaker-controld</code><span class="gmail-Apple-converted-space"> </span>logs:</p><pre style="color:rgb(0,0,0)"><code>pacemaker-controld[520998]: notice: Requesting local execution of stop operation for nginx_service on X.Y.Z
</code></pre><p style="color:rgb(0,0,0)">For puppetserver, I do not see a corresponding stop operation being requested.</p><p style="color:rgb(0,0,0)">The primitive definitions are:</p><pre style="color:rgb(0,0,0)"><code class="gmail-language-xml"><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>
</code></pre><p style="color:rgb(0,0,0)">Could someone please explain why Pacemaker requests a local stop operation for<span class="gmail-Apple-converted-space"> </span><code>nginx.service</code>, but not for<span class="gmail-Apple-converted-space"> </span><code>puppetserver.service</code>?<br>Is this related to differences in monitor intervals, systemd unit behavior, or Pacemaker’s internal state handling?</p><p style="color:rgb(0,0,0)">Thank you in advance for any insight.</p><p style="color:rgb(0,0,0)">Best regards,<br>Marek Pastierik</p></div>