[rabbitmq-discuss] Crash in rabbit_management_agent-2.7.0

Fri Nov 11 13:08:50 GMT 2011

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
/proc/self)

No idea why this happened after the upgrade - that setcap has been set
for ages, long before I upgraded to 2.7.0.

Thanks,
RJ

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.
>
>> /usr/local/lib/erlang/erts-5.8.1/bin/beam.smp
>
> 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:
>
> http://www.rabbitmq.com/releases/plugins/v2.7.0/rabbitmq_management_agent-2.7.0.proc-fix.ez
>
> - 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
>