trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan M. Carroll" <>
Subject Re: svn commit: r1096571 - in /trafficserver/traffic/trunk: lib/ts/ lib/ts/ lib/ts/ink_cap.h proxy/ proxy/http/ proxy/http/
Date Wed, 27 Apr 2011 14:00:40 GMT
I think it's a side effect. I wasn't sure if any one except my client was seeing the problem.
I have a potential fix.

The problem is related to the particular OS. On FC it works. On (for instance) Debian this
problem arises. The difference is that on the latter the server seems to start with a real
uid of 0 and an effective uid of nobody. This causes the setuid calls in to fail,
but because that's been moved forward the logging fails (because the log isn't available yet).
This cascades in to this problem but I still don't see why the permission is denied -- the
effective user id the same as the owner of the directory.

However, when I put a tweak in to recover an effective uid of 0 and then the switch to a real
and effective uid of nobody succeeds and then this permission check passes as well. Is Debian
using the real user id to check file permission and not the effective user id?

I will provide a patch as soon as I can. I can't just commit the changes I did at the client
because there's a lot of other carp from my experiments.

Wednesday, April 27, 2011, 3:10:26 AM, you wrote:

> I don't know if it's related to this change, but when running trunk, the
> startup script fails, running just traffic_manager shows this problem:

> [Apr 27 02:09:05.217] Server {47200722737184} NOTE: cache clustering disabled
> unable to access() log dir'/opt/ats/var/log/trafficserver': 13, Permission
> denied
> please set 'proxy.config.log.logfile_dir'

View raw message