Set stopsignal to KILL?

I guess setting stopsignal=kill is fine, given an orphan sleep process wouldn't be that bad.

Not ideal though the command invoked spawned other child processes that became orphaned? I'm not too familiar with zombie processes, and while it may not matter in this case I would like to avoid that concern when adopting this elsewhere in other projects.

EDIT: You can skip ahead to the "Revised" section at the end. I just discovered supervisord can target the process group and send each process the configured stopsignal, so that resolves that concern.

Why are you using bash -c and not just relying on shebang in the script?

If the script itself is my-command && sleep 25m, does it really need a separate script file with a shebang when you can just inline it like I showed? What benefit is there?

Reference - Existing implementation

supervisord config:

[program:getmail]
autostart=false
autorestart=true
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log
command=/bin/bash -l -c /usr/local/bin/getmail-service.sh

getmail-service.sh (partial content shown):

#!/bin/bash

# Kill all child processes on EXIT.
# Otherwise 'supervisorctl restart getmail' leads to zombie 'sleep' processes.
trap 'pkill --parent ${$}' EXIT

# If no matching filenames are found, and the shell option nullglob is disabled, the word is left unchanged.
# If the nullglob option is set, and no matches are found, the word is removed.
shopt -s nullglob

# Run each getmailrc periodically.
while :; do
  for RC_FILE in /etc/getmailrc.d/*; do
    getmail --getmaildir "${GETMAIL_DIR}" --rcfile "${RC_FILE}"
  done

  sleep "${GETMAIL_POLL}m"
done

I'm not sure why the login shell was necessary (I am not the author of the script), presumably due to their use of bash or the getmail program itself to ensure some ENV were set. - The for loop can be removed along with --rcfile option as that software has implemented functionality back in 2021 to iterate the --getmaildir for individual configs instead. - Perhaps when initially contributed to the project in 2023 the debian package used might have been too old at the time, or the contributor and reviewer(s) were not aware of the functionality (the getmail6 project on Github only documents it in a changelog entry and raw HTML docs, while linking to online docs that were last updated in 2020).

Simplified

So presumably this change to the supervisord config command would be fine:

[program:getmail]
command=bash -c 'getmail --getmaildir /var/lib/getmail && exec sleep %(ENV_GETMAIL_POLL)sm'

Or keeping the existing getmail-service.sh (but removing other stuff I didn't show, such as a stop method that calls supervisorctl, which has kinda prevented running this service as a non-root user):

[program:getmail]
command=/usr/local/bin/getmail-service.sh

#!/usr/bin/env bash

# Bail early if getmail exits with non-zero
set -e

# This still seems necessary to handle forwarding SIGTERM,
# (at least while the getmail command is actively running)
trap 'pkill --parent $$' EXIT

# No while loop anymore,
# Now relying upon supervisord `autorestart=true`
getmail --getmaildir /var/lib/getmail
exec sleep "${GETMAIL_POLL}m"

• The trap to kill the process group for the most part makes using exec with sleep redundant, so I could drop the exec.
• As I'm using supervisord in this scenario, I could also replace the bash trap with the supervisor service setting stopasgroup=true (sends SIGTERM to all process in the process group).

UPDATE - Revised

Leaning into supervisord more, no need for trap/exec or set -e (since script is basic enough && is sufficient?), so do away with that script and just inline a bash command like this?:

[program:getmail]
autorestart=true
stopasgroup=true
command=bash -c 'getmail --getmaildir /var/lib/getmail && sleep %(ENV_GETMAIL_POLL)sm'

I think that should work pretty well and meets my expectations AFAIK (a separate executable that doesn't depend upon supervisord + bash would be pretty sweet too though).