You should provide more context with the PR, appears to be as identified here: #4579 (comment)

End of that comment I am unsure of the current PR approach resolving the problem properly due to change detection still being racey (although the issue should be less frequently encountered by dropping the redundant restart). I proposed for change detection to be refactored with adopting watchexec in future that would resolve the concern.

In rspamd is restarted twice, once in _setup_default_signing_conf and the second time in _final_steps as it is mentioned in the referenced issue.
In my case I have failed tests:
https://github.com/scristian71/docker-mailserver/actions/runs/20618435610
And also if I run locally "[Rspamd] (DKIM)" I had random failures.

TL;DR:

• Please try and verify the following change suggestions (changing from restart to reload via SIGHUP):
  • Change:
    

    docker-mailserver/target/bin/rspamd-dkim

    Lines 277 to 284 in 0f5763c

    	function _final_steps() {
    	# We need to restart Rspamd so the changes take effect immediately.
    	if ! supervisorctl restart rspamd; then
    	_log 'warn' 'Could not restart Rspamd via Supervisord'
    	fi
    	_log 'trace' 'Finished DKIM key creation'
    	}

    
    to:

    function _final_steps() {
      # Request Rspamd to reload it's config immediately (instead of waiting on change detection):
      pkill --signal SIGHUP $(pgrep --oldest rspamd)
    
      _log 'trace' 'Finished DKIM key creation'
    }

  • Change:
    

    docker-mailserver/target/scripts/check-for-changes.sh

    Lines 209 to 210 in 0f5763c

    	_log 'debug' 'Rspamd configuration has changed - restarting service'
    	supervisorctl restart rspamd

    
    to:

    _log 'debug' 'Reloading Rspamd configuration'
    pkill --signal SIGHUP $(pgrep --oldest rspamd)

In my case I have failed tests:
https://github.com/scristian71/docker-mailserver/actions/runs/20618435610
And also if I run locally "[Rspamd] (DKIM)" I had random failures.

We recently landed a change that improved the rspamd test to avoid a failure that started appearing.

EDIT: I see your test run was from the merge commit of that PR, so the same spurious failure detailed in #4579 and referenced in #4627 (comment)

Change detection is presently at a default 2s poll rate, Rspamd can take a few seconds to complete a restart IIRC. So depending on how close the two restarts are from change detection and the setup config dkim script, any of the relevant rspamd_dkim.bats test cases may still fail.

EDIT: Sending a SIGHUP signal to Rspamd for it to reload config might avoid the concern.

In rspamd is restarted twice, once in _setup_default_signing_conf and the second time in _final_steps as it is mentioned in the referenced issue.

Yes, but it will still be possible that it is triggered and causes this failure even with your PR here.

Here is our change detection logic for rspamd support, it will detect the DKIM files created, then at the end of the snippet restart the rspamd service:

The DKIM keys generated into the DMS Config Volume rspamd/dkim/ dir will trigger that:

Just depends on the timing 🤔

The logic for both were contributed for DMS v13 back in 2023, where I raised some concerns:

• Sending a SIGHUP signal would be better than a restart to reload Rspamd instead of a full service restart. There was a concern expressed about SIGHUP not being supported and it's not entirely clear if that's still valid in 2026.
• The change detection concern was also raised at the time. There was a reply but it was focused on the dkim_signing.conf file only, the DKIM keys still result in a trigger.

So technically both restarts in this Rspamd DKIM script could be avoided I think? (LDAP is now enabled for change detection support, so I think that'll go smoothly). Doing so would make the following commentary a bit redundant?:

We may still want to go ahead with the immediate copy though, but instead of a restart a SIGHUP could be sent to request rspamd to reload it's configs via pkill --signal SIGHUP $(pgrep --oldest rspamd) (Side-note: We don't have rspamd covered in our service restart tests)

I have added the changes suggested by @ap-wtioit and the tests are passing now:

https://github.com/scristian71/docker-mailserver/actions/runs/20793106916

This is in response to @ap-wtioit review input, but on the main thread to keep the added information below visible.

Also pkill does not accept pids, when using pgrep to get the pid use kill

Whoops that's my bad sorry 😓

I was referencing some test logic I wrote a while back but didn't pay attention to how the PID was used.

This is additional context for my benefit on the topic. No need to read below this unless it interests you 👍

Notes

Using the rspamd process name with --oldest should still work well, just pgrep itself isn't necessary:

$ pgrep --oldest rspamd
1360

$ pgrep --list-full rspamd
1360 rspamd: main process
1639 rspamd: rspamd_proxy process (127.0.0.1:11332)
1640 rspamd: rspamd_proxy process (127.0.0.1:11332)
1641 rspamd: controller process (0.0.0.0:11334)
1642 rspamd: hs_helper process

# Reload (NOTE: `--echo` produces the output lines instead of being silent):
$ pkill --echo --signal SIGHUP rspamd
rspamd killed (pid 1360)
rspamd killed (pid 1639)
rspamd killed (pid 1640)
rspamd killed (pid 1641)
rspamd killed (pid 1642)

# Only sends signal to the main rspamd process:
# (NOTE: This still respawns the child processes)
$ pkill --oldest --echo --signal SIGHUP rspamd
rspamd killed (pid 1360)

# Original PID 1360 wasn't actually "killed":
# (Child processes were respawned)
$ pgrep --full --list-full rspamd
1360 rspamd: main process
2115 rspamd: rspamd_proxy process (127.0.0.1:11332)
2116 rspamd: rspamd_proxy process (127.0.0.1:11332)
2117 rspamd: controller process (0.0.0.0:11334)
2118 rspamd: hs_helper process

# Process tree (`pstree` via `psmisc` package):
$ pstree -p -s "$(pgrep --oldest rspamd)"
dumb-init(1)---supervisord(7)---rspamd(1360)-+-rspamd(2115)
                                             |-rspamd(2116)
                                             |-rspamd(2117)
                                             `-rspamd(2118)

NOTE: The increasingly larger PID of the child processes appears to be from check-for-changes.sh calling sleep 2 in a loop with each invocation incrementing the PID (along with any other commands I use via CLI).

Related logs (different PIDs from another run), completes within 1 second:

2026-01-07 20:59:33 #635(main) <e96fe3>; main; rspamd_hup_handler: rspamd 3.12.1 is requested to reload configuration
# ...
2026-01-07 20:59:34 #635(main) <e96fe3>; main; reread_config: config has been reread successfully
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_hup_handler: spawn workers with a new config
2026-01-07 20:59:34 #635(main) <e96fe3>; main; spawn_workers: worker of type fuzzy(localhost:11335) is disabled in the config, skip spawning
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_fork_worker: prepare to fork process rspamd_proxy (0); listen on: 127.0.0.1:11332
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_fork_worker: prepare to fork process rspamd_proxy (1); listen on: 127.0.0.1:11332
2026-01-07 20:59:34 #1261(rspamd_proxy) <e96fe3>; main; rspamd_worker_set_limits: use system max file descriptors limit: 1024KiB cur and 1024KiB max
2026-01-07 20:59:34 #1261(rspamd_proxy) <e96fe3>; main; rspamd_worker_set_limits: use system max core size limit: -1B cur and -1B max
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_fork_worker: prepare to fork process controller (0); listen on: 0.0.0.0:11334
2026-01-07 20:59:34 #1262(rspamd_proxy) <e96fe3>; main; rspamd_worker_set_limits: use system max file descriptors limit: 1024KiB cur and 1024KiB max
2026-01-07 20:59:34 #1262(rspamd_proxy) <e96fe3>; main; rspamd_worker_set_limits: use system max core size limit: -1B cur and -1B max
2026-01-07 20:59:34 #635(main) <e96fe3>; main; spawn_workers: worker of type normal(127.0.0.1:11333) is disabled in the config, skip spawning
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_fork_worker: prepare to fork process hs_helper (0), no bind socket
2026-01-07 20:59:34 #1263(controller) <e96fe3>; main; rspamd_worker_set_limits: use system max file descriptors limit: 1024KiB cur and 1024KiB max
2026-01-07 20:59:34 #1263(controller) <e96fe3>; main; rspamd_worker_set_limits: use system max core size limit: -1B cur and -1B max
2026-01-07 20:59:34 #1263(controller) <19ntq8>; controller; rspamd_controller_password_sane: your normal password is not encrypted, we strongly recommend to replace it with the encrypted one
2026-01-07 20:59:34 #1263(controller) <19ntq8>; controller; rspamd_controller_password_sane: enable password is not set, so you should filter controller availability by using of firewall or `secure_ip` option
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_hup_handler: workers spawning has been finished
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_hup_handler: kill old workers
2026-01-07 20:59:34 #635(main) <e96fe3>; main; kill_old_workers: send signal to worker 806
2026-01-07 20:59:34 #635(main) <e96fe3>; main; kill_old_workers: send signal to worker 805
2026-01-07 20:59:34 #635(main) <e96fe3>; main; kill_old_workers: send signal to worker 804
2026-01-07 20:59:34 #635(main) <e96fe3>; main; kill_old_workers: send signal to worker 807
2026-01-07 20:59:34 #1264(hs_helper) <e96fe3>; main; rspamd_worker_set_limits: use system max file descriptors limit: 1024KiB cur and 1024KiB max
2026-01-07 20:59:34 #1264(hs_helper) <e96fe3>; main; rspamd_worker_set_limits: use system max core size limit: -1B cur and -1B max
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_check_termination_clause: hs_helper process 807 terminated normally
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_cld_handler: do not respawn process hs_helper after found terminated process with pid 807
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_check_termination_clause: rspamd_proxy process 804 terminated normally
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_cld_handler: do not respawn process rspamd_proxy after found terminated process with pid 804
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_check_termination_clause: controller process 806 terminated normally
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_cld_handler: do not respawn process controller after found terminated process with pid 806
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_check_termination_clause: rspamd_proxy process 805 terminated normally
2026-01-07 20:59:34 #635(main) <e96fe3>; main; rspamd_cld_handler: do not respawn process rspamd_proxy after found terminated process with pid 805

Rspamd service management and failure handling

If Rspamd service itself is not running, I don't think we need to start the service.

Supervisord handles restarting the main process when the service was started during container init, and it will handle restarting if the rspamd process is killed abruptly too (which is what the linked test case covers, albeit it is missing rspamd coverage it should still be handled the same).

• RSpamd has a wrong config and pkill "reloads" the config but fails to check the status (rspamd is dead)

Rspamd shouldn't be dead?

The actions run failure linked by @scristian71 has test cases fail with:

ERROR rspamd-dkim: Unexpected error occurred :: script = /usr/local/bin/rspamd-dkim  | function = _final_steps | command = pkill --signal SIGHUP $(pgrep --oldest rspamd) | line = 276 | exit code = 1

Not too different from the error at the start of my associated report (minus the earlier log lines related to a supervisorctl restart rspamd):

rspamd: ERROR (not running)
rspamd: ERROR (abnormal termination)
ERROR rspamd-dkim: Unexpected error occured :: script = /usr/local/bin/rspamd-dkim  | function = _setup_default_signing_conf | command = supervisorctl restart rspamd | line = 260 | exit code = 7

However the current failure of (exit code = 1) is occurring because (as you mentioned) the failure for pkill to kill by PID input:

$ pkill --signal SIGHUP 123
$ echo $?
1

I also tried to trigger a bad config failure, but this didn't affect the rspamd process in anyway. Even with a reload invoked.. when using rspamadm configdump it showed the bad config but no failure (possibly because the tool just dumps config), nor was anything showing up in /var/log/mail/rspamd.log (it would probably log errors if I triggered the functionality for the /etc/rspamd/override.d/multimap.conf invalid config I added).

I'm lacking further context on where bad config is causing rspamd to die in our test suite 😅

Side-Note - Accidental supervisord reload impact (SIGHUP to PID 1)

If we ran into a scenario that caused pkill --signal SIGHUP '' (by getting an empty pgrep subshell response with the quote wrapping advised from AI suggestions), this would actually restart everything in the container as supervisord receives the SIGHUP signal. That in turn brings down Rspamd temporarily.

$ docker compose up -d --force-recreate
$ docker compose exec dms bash

# When no PID is given, the empty string input sends the signal to every process:
# (thus the `supervisord` process, as an empty string matches all processes)
$ pkill --signal SIGHUP ""

# The previous command also booted you out of the container (bash process reloaded):
$ docker compose exec dms bash

# `supervisord` reloads due to `SIGHUP`, this restarts the DMS container init script
# which results in rspamd and other services being started again...
# - New rspamd process running for 17s
# - NOTE: If you ran this command too early, it'll still have the existing rspamd service time
$ ps -p "$(pgrep --oldest rspamd)" -o etimes=
     17

Inspecting /var/log/supervisor/supervisord.log we can see this is the case:

2026-01-07 21:16:27,106 WARN exited: mailserver (terminated by SIGHUP; not expected)
2026-01-07 21:16:27,164 WARN exited: update-check (terminated by SIGHUP; not expected)
2026-01-07 21:16:27,164 WARN exited: changedetector (terminated by SIGHUP; not expected)
2026-01-07 21:16:27,165 WARN received SIGHUP indicating restart request
2026-01-07 21:16:54,648 WARN stopped: cron (terminated by SIGTERM)

After the pkill command boots you out of container, we can go back in and see how this affects the rspamd service that supervisord manages:

$ supervisorctl status rspamd
error: <class 'xmlrpc.client.Fault'>, <Fault 6: 'SHUTDOWN_STATE'>: file: /usr/lib/python3.11/xmlrpc/client.py line: 668

# Try again:
$ supervisorctl status rspamd
rspamd                           STOPPED   Not started

# Try again:
$ supervisorctl status rspamd
rspamd                           RUNNING   pid 6271, uptime 0:00:01

EDIT: Turns out it wasn't just PID 1 and forwarding to supervisord that our ENTRYPOINT + CMD instructions in the Dockerfile configure, but all processes are matched and received the SIGHUP 😬

$ pkill --echo --signal SIGHUP ''

dumb-init killed (pid 1)
supervisord killed (pid 6)
tail killed (pid 7768)
cron killed (pid 7908)
rsyslogd killed (pid 7912)
dovecot killed (pid 7918)
anvil killed (pid 7923)
log killed (pid 7924)
config killed (pid 7925)
update-check.sh killed (pid 7927)
redis-server killed (pid 7953)
sleep killed (pid 7966)
rspamd killed (pid 7967)
pidproxy killed (pid 7973)
postfix-script killed (pid 7977)
check-for-chang killed (pid 8004)
rspamd killed (pid 8006)
rspamd killed (pid 8007)
rspamd killed (pid 8008)
rspamd killed (pid 8011)
master killed (pid 8093)
pickup killed (pid 8094)
qmgr killed (pid 8095)
bash killed (pid 8096)
sleep killed (pid 9126)

I could see how the supervisord reload would result in encountering rspamd in a bad state, or the process not being visible briefly (or appearing dead).

pkill --signal SIGHUP $(pgrep --oldest rspamd) still results in a exit code of 1 just the same though.. it's only a bigger concern if it was given an empty input with via quotes:

# Error (exit code 2):
$ pkill --signal SIGHUP $(pgrep --oldest rspamdx)
pkill: no matching criteria specified
Try `pkill --help' for more information.

# The `pgrep` subshell returns an empty return value,
# all PID are matched and given the `SIGHUP` signal:
$ pkill --signal SIGHUP "$(pgrep --oldest rspamdx)"

I was about to write a comment for the _reload_rspamd utils method. When i read Supervisor/supervisor#53 once again and came to Supervisor/supervisor#53 (comment). It seems there is a supervisorctl signal SIGHUP rspamd that should do what we need to reload Rspamd.

Edit: confirmed that for us the tests are working with supervisorctl signal SIGHUP rspamd in both target/bin/rspamd-dkim and target/scripts/check-for-changes.sh

I have applied the suggested changes. Locally the tests are passing.