This repository was archived by the owner on Feb 25, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 72
prometheus_process_collector plugin crash when /var/lib/rabbitmq is noexec #26
Labels
Comments
Thanks a lot, for this issue and for all debugging assistance. You are awesome :-) Basically this is the perfect example why I do open source :-) |
Hi, I'm hitting the same or similar issue, however changing
|
maybe arch/glibc didn't match? you can rebuild the plugin yourself - clone https://github.com/deadtrickster/prometheus_process_collector and run |
@Rotwang did you try to rebuild prometheus_process_collector yourself? |
DXist
pushed a commit
to DXist/prometheus_rabbitmq_exporter
that referenced
this issue
Dec 28, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As explained in #12 (comment) , the
prometheus_process_collector
plugin aborts the booting of RabbitMQ when theRABBITMQ_PLUGINS_EXPAND_DIR
points to a directory which is mounted with noexec flag (or which is associated with a selinux policy which prevents executing code).I found the issue trying to run RabbitMQ packaged as an Openshift3 (kubernetes) pod which persists its data to a persistent directory on the host. Since the Centos7 host has SELinux enabled by default, I had to
chcon -Rt svirt_sandbox_file_t /data/rabbitmq
to make the persistent directory available to the docker container. RabbitMQ booted fine until I modified my Dockerfile to enable theprometheus_process_collector
; I then found out that thesvirt_sandbox_file_t
label on the directory only enables read and writes on the directory, enforcing the equivalent of the "noexec" mount flag. This made the loading of the native code in the plugin fail and aborted the boot.Simple steps to reproduce:
Workaround: explictly set the
RABBITMQ_PLUGINS_EXPAND_DIR
environment variable to point to a path where code can be executed, for exampleRABBITMQ_PLUGINS_EXPAND_DIR=/tmp/rabbitmq-expand-plugins
. Note that the parent directory ofRABBITMQ_PLUGINS_EXPAND_DIR
must be writable by the RabbitMQ user, because RabbitMQ will try torm -rf ${RABBITMQ_PLUGINS_EXPAND_DIR}
on boot.In other words, run the container like this:
The text was updated successfully, but these errors were encountered: