The message boards here are just fine. You can either copy/paste them in a code block or compress them and upload them directly. What I'm looking for is something like this as part of the hadoop client install on a host with the problem: 2016-08-31 15:50:29,421 - Checking if need to create versioned conf dir /etc/hadoop/2.4.2.0-236/0 2016-08-31 15:50:29,422 - call[('ambari-python-wrap', '/usr/bin/conf-select', 'dry-run-create', '--package', 'hadoop', '--stack-version', '2.4.2.0-236', '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False, 'stderr': -1} 2016-08-31 15:50:29,439 - call returned (0, '/etc/hadoop/2.4.2.0-236/0', '') 2016-08-31 15:50:29,439 - Package hadoop will have new conf directories: /etc/hadoop/2.4.2.0-236/0 2016-08-31 15:50:29,439 - Checking if need to create versioned conf dir /etc/hadoop/2.4.2.0-236/0 2016-08-31 15:50:29,440 - call[('ambari-python-wrap', '/usr/bin/conf-select', 'create-conf-dir', '--package', 'hadoop', '--stack-version', '2.4.2.0-236', '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False, 'stderr': -1} 2016-08-31 15:50:29,457 - call returned (0, '/etc/hadoop/2.4.2.0-236/0', '') ... 2016-08-31 15:50:29,492 - checked_call[('ambari-python-wrap', '/usr/bin/conf-select', 'set-conf-dir', '--package', 'hadoop', '--stack-version', '2.4.2.0-236', '--conf-version', '0')] {'logoutput': False, 'sudo': True, 'quiet': False} 2016-08-31 15:50:29,509 - checked_call returned (0, '/usr/hdp/2.4.2.0-236/hadoop/conf -> /etc/hadoop/2.4.2.0-236/0') 2016-08-31 15:50:29,510 - Ensuring that hadoop has the correct symlink structure ... View more

This seems like a bug, perhaps caused by client-only hosts. /etc/<component>/conf -> /usr/hdp/current/hadoop-client/conf is correct. What should have happened is that conf-select should have changed /usr/hdp/current/hadoop-client/conf to point to something like /usr/hdp/2.5.0.0-1234/hadoop/conf/0 I'm guessing that the conf-select step failed. If you could post the entire output from your client install command, that can help us determine why it failed. ... View more

Ah, OK - I had misread the directory is /usr/hdp/current; indeed etc and other directories are allowed in /usr/hdp/2.3.6.0-3796 Ambari actually doesn't do anything with those directories. We only manipulate the symlinks in /usr/hdp/current and /etc I'm curious if this is a problem with 2.3.4.0 ... View more

/usr/hdp/2.3.4.0-3485/etc/default/accumulo That's not a correct file location. Everything under /usr/hdp/2.3.4.0-3485 must be HDP component names, like accumulo-tablet or accumulo-client. I'm not sure how that directory is constructed in the Accumulo files, but something seems to have an invalid value. Perhaps Accumulo isn't looking in the correct location for configuration files? Could it be trying to look in /etc/default/accumulo which doesn't exist? ... View more

This could be the same issue being discussed here: https://community.hortonworks.com/questions/53203/ambari-is-showing-alerts-on-the-accumulo-service-e.html#answer-53351 Seems like Accumulo doesn't bind to the port after startup. ... View more

When you add a new host to a cluster the services running on that host are not automatically started (but they are installed). You will need to startup the services on that new host for the alerts to go away. ... View more

So, it sounds like AMBARI-14847 is the problem. If you upgrade to Ambari 2.2.2, that should resolve it. ... View more

It could be https://issues.apache.org/jira/browse/AMBARI-14847, a problem with concurrent kinit calls. This was fixed in Ambari 2.2.2 - which version of Ambari is this? ... View more