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 Main.cc 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'
