[Bug 258488] net/rabbitmq: fix pidfile in rabbitmq rc.d script
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 258488] net/rabbitmq: fix pidfile in rabbitmq rc.d script"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.