[rabbitmq-discuss] Crash in rabbit_management_agent-2.7.0
simon at rabbitmq.com
Fri Nov 11 13:22:32 GMT 2011
Cool. Thanks for getting back to the list. So yes, the fix will probably
go in some future release, but I'm glad to hear it's not a priority...
On 11/11/11 13:08, Richard Jones wrote:
> Ah, got it - bit of a weird one:
> This erlang install has the beam.smp process setcap'ed to allow it to
> bind ports<1024 without running as root.
> # getcap /usr/local/lib/erlang/erts-5.8.1/bin/beam.smp
> /usr/local/lib/erlang/erts-5.8.1/bin/beam.smp = cap_net_bind_service+ep
> Once I do this to remove the capability:
> # setcap cap_net_bind_service=-ep /usr/local/lib/erlang/erts-5.8.1/bin/beam.smp
> this fixes the problem, and everything in proc/pid is owned by
> rabbitmq as expected.
> If i "setcap cap_net_bind_service=+ep vim" the same thing happens, so
> looks like a general setcap issue.
> Setcap isn't like suid, the process wasn't running as root or really
> with root perms (just that it can bind ports<1024), but apparently it
> was confused enough to break proc ownership. Don't know what the
> intended behaviour is, can't find any warnings in the setcap docs
> (which are sparse).
> Sorry for the wild goose chase.. As it happens, I'm using an iptables
> redirect now anyway, so don't need the setcap anymore.
> I put the cap back on, and tested your fixed plugin: it boots up fine
> with the fixed management_agent plugin installed. Might be worth
> leaving that in as a fallback (and anywhere else that checks
> No idea why this happened after the upgrade - that setcap has been set
> for ages, long before I upgraded to 2.7.0.
> On 11 November 2011 12:52, Simon MacMullen<simon at rabbitmq.com> wrote:
>> On 11/11/11 12:19, Richard Jones wrote:
>>> Conversely, if I just start vim, like so:
>>> su rabbitmq -s /bin/sh -c "vim"
>>> then everything in the /proc/PID dir *is* owned by rabbitmq.
>>> If I just start erl, it's the same as starting rabbit (proc/PID/fd
>>> owned by root)
>>> At a bit of a loss.
>> Yeah, that doesn't make sense to me either.
>> This is the only thing to leap out - you have a self compiled Erlang but you
>> installed RabbitMQ using the .deb? I still don't see how that would be the
>> issue though.
>> Anyway, I've put a management agent plugin that should handle failure to
>> open /proc/<pid>/fd at:
>> - could you download this to
>> /usr/lib/rabbitmq/lib/rabbitmq_server-2.7.0/plugins/, delete the other
>> management-agent, and see if this fixes the problem?
>> Cheers, Simon
>> Simon MacMullen
>> RabbitMQ, VMware
More information about the rabbitmq-discuss