accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Miller <>
Subject Re: ChangeSecret Utility
Date Wed, 13 Jul 2016 17:07:15 GMT
After further debugging, I don't think the problem is with the JCommander
classes directly.  I have isolated the problem to be with something in the
accumulo shell. When I run the ChangeSecret utility as a standalone java
program on the command line, it has no problem accepting input. Any idea
what in the shell might be causing this issue? Is there something else
accepting input that could be interfering?

On Tue, Jul 12, 2016 at 12:02 PM, Mike Miller <>

> It looks the problem is with the parsing of the arguments in the
> JCommander classes. When I run ChangeSecret through the Eclipse debugger it
> uses the DefaultConsole.readPassword method to read in the password and it
> seems to take my input correctly. When I ran the utility through the
> accumulo script and attached jdb, it looks like its using an internal class
> called JDK6Console to read the password. The simple fact that it has a JDK
> version in the name (I am running Java 1.8) gives me the feeling this might
> be the problem.  I will keep investigating.
> On Tue, Jul 12, 2016 at 10:43 AM, Josh Elser <> wrote:
>> Mike Miller wrote:
>>> I was looking at the bug ACCUMULO-2971
>>> <>  but I am unable
>>> to
>>> get the ChangeSecret utility to run. I also noticed the bug 2972
>>> <>  which states the
>>> documentation should instruct the user to run the utility as so:
>>> accumulo org.apache.accumuloserver.util.ChangeSecret
>>> I have a standalone instance of 1.7.2 setup on my machine. I am running
>>> the
>>> utility as myself, which is also the user that is running Hadoop and who
>>> has control over the files in HDFS, but when the utility prompts for the
>>> passwords, it is only letting me enter a single keystroke for each
>>> password. Then I get an
>>> org.apache.zookeeper.KeeperException$NoAuthException because I am unable
>>> to
>>> enter the passwords correctly.
>> That's weird.
>> Christopher suggested that it might be an issue with the latest JLine jar
>>> (2.11) so I pulled down the older jar (2.10) and replaced the newer jar
>>> in
>>> my lib. This didn't seem to have any effect. Could this be an issue with
>>> my
>>> local install?
>> It might just be broken. It's not something that is commonly used, and
>> has probably atrophied.
>> Have you tried to attach a remote debugger to the process (you can put
>> the JVM properties into ACCUMULO_GENERAL_OPTS via to trace
>> through what it's doing?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message