Skip to content

fixes #973 - Do not restart agent service on package changes#981

Open
Flo2388 wants to merge 2 commits intotheforeman:masterfrom
Flo2388:fix-973/adjust-restart-behaviour
Open

fixes #973 - Do not restart agent service on package changes#981
Flo2388 wants to merge 2 commits intotheforeman:masterfrom
Flo2388:fix-973/adjust-restart-behaviour

Conversation

@Flo2388
Copy link
Copy Markdown

@Flo2388 Flo2388 commented Mar 24, 2026

Change the relationship between puppet::agent::install and puppet::agent::config/puppet::agent::service from notification (~>) to ordering-only (->). The notification caused a reload-or-restart of the agent service immediately after a package upgrade, which killed the newly started service and left it in a failed state.

When upgrading the openvox-agent package (e.g. 8.23.1 → 8.24.1), the following race condition occurs:

  1. The running puppet agent (PID A) applies the package resource, spawning apt-get/dpkg as child processes.

  2. The package's postinst script calls systemctl try-restart puppet. systemd stops the service and sends SIGTERM to the main service PID.

  3. PID A and its children (apt-get, dpkg) survive as orphan processes in the cgroup because they are child processes, not the main PID tracked by systemd.

  4. The postinst script starts a new puppet service (PID B). The service is now healthy.

  5. The orphaned PID A finishes the package resource and, due to the ~> (notification) relationship, triggers reload-or-restart on the puppet service. This sends SIGHUP to PID B — the service that was just started in step 4.

  6. PID B exits, the service enters the dead state, and no puppet agent is running.

Changing ~> to -> between puppet::agent::install and puppet::agent::service preserves ordering but removes the redundant notification. The package postinst already handles the service restart during upgrades.

Change the relationship between puppet::agent::install and
puppet::agent::config/puppet::agent::service from notification (~>)
to ordering-only (->). The notification caused a reload-or-restart
of the agent service immediately after a package upgrade, which
killed the newly started service and left it in a failed state.

When upgrading the openvox-agent package (e.g. 8.23.1 → 8.24.1), the
following race condition occurs:

1. The running puppet agent (PID A) applies the package resource,
   spawning apt-get/dpkg as child processes.

2. The package's postinst script calls systemctl try-restart puppet.
   systemd stops the service and sends SIGTERM to the main service PID.

3. PID A and its children (apt-get, dpkg) survive as orphan processes
   in the cgroup because they are child processes, not the main PID
   tracked by systemd.

4. The postinst script starts a new puppet service (PID B). The
   service is now healthy.

5. The orphaned PID A finishes the package resource and, due to the
   ~> (notification) relationship, triggers reload-or-restart on the
   puppet service. This sends SIGHUP to PID B — the service that was
   just started in step 4.

6. PID B exits, the service enters the dead state, and no puppet
   agent is running.

Changing ~> to -> between puppet::agent::install and
puppet::agent::service preserves ordering but removes the redundant
notification. The package postinst already handles the service
restart during upgrades.
…:config/puppet::agent::service to ensure proper ordering. Changed notification to ordering-only to prevent service restart issues during package upgrades.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant