[Bug 258488] net/rabbitmq: fix pidfile in rabbitmq rc.d script

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 05 Oct 2021 11:13:44 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258488

Dave Cottlehuber <dch@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |In Progress

--- Comment #2 from Dave Cottlehuber <dch@freebsd.org> ---
This gets messy fast! None of the options so far produce a good result.

- RabbitMQ in general expects its pidfile to be the BEAM process
- using daemon(8) sets the FreeBSD pidfile to the rabbitmq-server shell script
- rabbitmq-server docs are in fact incorrect, the pidfile is written
    even when `-detached` is set
- we don't know what the pidfile is going to be inside RabbitMQ really
- RabbitMQ *needs* to have a writable pidfile location as its Elixir helper
scripts will wait for the file to appear (so truncation is not an option)

According to https://www.rabbitmq.com/relocate.html RabbitMQ has its
pidfile defined here:

RABBITMQ_PID_FILE

Which expands to (by default):

/var/db/rabbitmq/mnesia/rabbit@${HOSTNAME}.pid

Which is not at all FreeBSD hier(7) nor POLA, but is exactly where a
RabbitMQ person would look for it, and where all the tools expect it to
be.

The rc.d script sets this pidfile variable, but RabbitMQ ignores it as env vars
are not passed through to su nor daemon.

```
# ps -dU rabbitmq
PID    STAT TIME   COMMAND
47303  I    0:00.01 /bin/sh /usr/local/sbin/rabbitmq-server
71950  I    0:07.19 - /usr/local/lib/erlang24/erts-12.1.1/bin/beam.smp ...
41316  Ss   0:00.10 `-- erl_child_setup 65000
   69  Is   0:00.00   `-- inet_gethost 4
15065  I    0:00.00     `-- inet_gethost 4

# cat /var/db/rabbitmq/mnesia/rabbit@wintermute.pid
71950

# cat /var/run/rabbitmq.pid
47303

# cat /var/run/rabbitmq-daemon.pid
43693

# pgrep -ilf daemon|grep rabb
43693 daemon: /usr/local/sbin/rabbitmq-server[47303]
```

wrt using daemon(8), I'm generally not in favour of this for
network-facing systems; if the application crashes, we want to fix that,
and not just restart and YOLO our way through whatever issue crops up.

For example, if the app crashes on malicious input, then it may be
possible to use this crash as a side channel to extract credentials.

That said, if you have need of it, I'm ok with switching back, I just
need to understand what's broken so I am sure we fix it this time.

I can roll this into the 3.9.7 update I'm preparing just now, and
backport that to quarterly.

Does the rc.d script behave correctly for your needs?
Do you need knowledge of /var/run/rabbitmq.pid outside of the rc.d script at
all?

I don't think daemon(8) helps here, it just makes more incorrect
pidfiles. And the only sensible choice is the rabbitmq default,
which would mean we have no $pidfile at all in the rc.d script.

What should we do here?

-- 
You are receiving this mail because:
You are the assignee for the bug.