Hello, Christopher >The stack trace doesn't include anything from Accumulo, so it's not clear >where in the Accumulo code this occurred. Do you have the full stack trace? Yes, I understand the stack trace isn't including from Accumulo. I don't have full stack trace now, but I will try to find it.
In additon, I use Accumulo on AWS EMR cluster for Enterprise Production System, so log level isn't debug, becase of disk capacity problem. I will try to reproduce with debug log level. Thank you for your reply, Takashi 2016-12-04 18:00 GMT+09:00 Christopher <[email protected]>: > The stack trace doesn't include anything from Accumulo, so it's not clear > where in the Accumulo code this occurred. Do you have the full stack trace? > > In particular, it's not clear to me that there should be a directory called > failed/da at that location, nor is it clear why Accumulo would be trying to > check for the execute permission on it, unless it's trying to recurse into a > directory. There is one part of the code where, if the directory exists when > log recovery begins, it may try to do a recursive delete, but I can't see > how this location would have been created by Accumulo. If that is the case, > then it should be safe to manually delete this directory and its contents. > The failed marker should be a regular file, though, and should not be a > directory with another directory called "da" in it. So, I can't see how this > was even created, unless by an older version or another program. > > The only way I can see this occurring is if you recently did an upgrade, > while Accumulo had not yet finished outstanding log recoveries from a > previous shutdown, AND the previous version did something different than > 1.7.2. If that was the case, then perhaps the older version could have > created this problematic directory. It seems unlikely, though... because > directories are usually not created without the execute bit... and the error > message looks like a directory missing that bit. > > It's hard to know more without seeing the full stack trace with the relevant > accumulo methods included. It might also help to see the master debug logs > leading up to the error. > > On Sun, Dec 4, 2016 at 2:35 AM Takashi Sasaki <[email protected]> wrote: >> >> I use Accumulo-1.7.2 with Haddop2.7.2 and ZooKeeper 3.4.8 >> >> Master server suddenly throw AccessControlException. >> >> java.io.IOException: >> org.apache.hadoop.security.AccessControlException: Permission denied: >> user=accumulo, access=EXECUTE, >> >> inode="/accumulo/recovery/603194f3-dd41-44ed-8ad6-90d408149952/failed/da":accumulo:accumulo:-rw-r--r-- >> at >> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:319) >> at >> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:259) >> at >> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:205) >> at >> org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:190) >> at >> org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkPermission(FSDirectory.java:1720) >> at org.apache.hadoop.hdfs.server.namenode.FSDirSt >> at AndListingOp.getFileInfo(FSDirSt >> at AndListingOp.java:108) >> at >> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getFileInfo(FSNamesystem.java:3855) >> at >> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getFileInfo(NameNodeRpcServer.java:1011) >> at >> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTransl >> at orPB.getFileInfo(ClientNamenodeProtocolServerSideTransl >> at orPB.java:843) >> at >> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) >> at >> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616) >> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969) >> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2049) >> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2045) >> at java.security.AccessController.doPrivileged(N >> at ive Method) >> at javax.security.auth.Subject.doAs(Subject.java:422) >> at org.apache.hadoop.security.UserGroupInform >> at ion.doAs(UserGroupInform >> at ion.java:1657) >> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2043) >> >> >> How can I solve this Exception? >> >> >> Thank you, >> Takashi.
