Foreman application server (Puma) status monitoring

This post describes steps to monitor and control the puma service in production environment on RPM based distribution. It is working with Foreman 3.0 and newer. Tested on CentOS 7 and CentOS 8 Stream distributions. On CentOS 7 you need to wrap up commands in scl enable tfm '$command'.

Using pumactl for gettings stats or gc-stats

# RHEL 7 like system
scl enable tfm 'pumactl stats -S /usr/share/foreman/tmp/puma.state'
# RHEL 8 / CentOS 8 Stream like
pumactl stats -S /usr/share/foreman/tmp/puma.state
pumactl gc-stats -S /usr/share/foreman/tmp/puma.state

example outpus:





To display puma user friendly status, run this


this gives you info about the CPU and memory usage, number of requests, current load

It works on both 7 and 8 Stream. It does not have execution permission by default, that’s why you need to add sh to the command.

For continuous monitoring, you can use watch like this

watch --color --interval 1 sh ~foreman/script/foreman-puma-status

For the historical reasons I’m also keeping pre 3.0 notes which may work to some degree

For version with Foreman older than 3.0 see previous versions of this wiki


In Fixes #29507 - Add puma-status for reporting by ehelms · Pull Request #7735 · theforeman/foreman · GitHub we force the control app path which should avoid the private tmp problem. Isn’t that an easier solution?

1 Like

Thanks for linking the PR, once it’s merged I’ll update the post (I made it a wiki already)

As puma is already using sd_notify, would it make sense to have this always in systemctl status output? If yes, I think an issue or pull-request would be considered upstream.

The puma-status gem is extremely useful and it is pretty simple, I wonder if we could integrate this onto our About page :slight_smile:

Nice writeup.

I do think it would be considered. It was in GitHub - sj26/puma-plugin-systemd: Puma integration with systemd for better daemonising under modern Linux systemds: notify, status, watchdog but that plugin kept getting out of sync so I finished a PR by another contributor that at least gave the minimal parts we needed. Implementing what you suggest is a good idea.

IMHO about is the wrong place. If you have a load balanced Foreman, there is just information about the current host.

I created Utilize systemd-notify to add status details · Issue #2604 · puma/puma · GitHub, so we will see what happens.

Note that what was originally added to the puma-plugin-systemd for systemctl output was basic worker and thread count information. The puma-status gem displays more data such as memory and load. If they’d accept all things puma-status shows to be displayed there it would be nice all in one solution. Until then, we have one week till stabilization so if we’d like puma-status reporting (which I would like) reviews of Fixes #29507 - Add puma-status for reporting by ehelms · Pull Request #7735 · theforeman/foreman · GitHub would be appreciated so I can also get the packaging part done.

I’ve updated the wiki with much easier use now, also with example outputs.


Should it use /usr/sbin/foreman-puma-status instead of sh ~foreman/script/foreman-puma-status? That’s what we actually support and should also work on Debian.

Why we ship the script then? That seems to correctly handle SCL on el7.

I think it is an oversight. We first patch the script here:

Then we copy it to the final location:

However, we then don’t exclude the actual script. Looking at it, there may be more scripts that are shipped twice or could be excluded.

ok, thanks for sharing, updated