Troubleshooting Installation Problems
This topic describes common installation issues and suggested solutions.
- TLS Protocol Error with OpenJDK
- Navigator HSM KMS Backed by Thales HSM installation fails
- Failed to start server reported by cloudera-manager-installer.bin
- Installation interrupted and installer does not restart
- Cloudera Manager Server fails to start with MySQL
- Agents fail to connect to Server
- Cluster hosts do not appear
- "Access denied" in install or update wizard
- Databases fail to start.
- Cloudera services fail to start
- Activity Monitor displays a status of BAD
- Activity Monitor fails to start
- Attempts to reinstall lower version of Cloudera Manager fail
- Create Hive Metastore Database Tables command fails
- Oracle invalid identifier
TLS Protocol Error with OpenJDK
If you are using an older version of OpenJDK 1.8 and have enabled SSL/TLS for the Cloudera Manager Admin Console, you may encounter a TLS protocol error when connecting to the Admin Console, stating that there are no ciphers in common. This is because older versions of OpenJDK may not implement certain TLS ciphers, causing an inability to log into the Cloudera Manager Admin Console when TLS is enabled.
Workaround:
- Upgrade OpenJDK to a supported version of OpenJDK that is higher than version 1.8.0_181.
- If it is not possible to upgrade OpenJDK, enable less secure TLS ciphers in Cloudera Manager. You can do this by opening the /etc/default/cloudera-scm-server in a text editor and adding the following line:
export CMF_OVERRIDE_TLS_CIPHERS=<cipher_list>
Where <cipher_list> is a list of TLS cipher suites separated by colons. For example:export CMF_OVERRIDE_TLS_CIPHERS="TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA:TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA:TLS_EDH_RSA_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA"
Cloudera Bug: OPSAPS-49578
Navigator HSM KMS Backed by Thales HSM installation fails
ERROR: Hadoop KMS could not be started REASON: com.ncipher.provider.nCRuntimeException: com.ncipher.km.nfkm.nfkmCommunicationException The nfkm command program has terminated unexpectedly.
Possible Reasons
The KMS user is not part of the nfast group on the host(s) running the Navigator HSM KMS backed by Thales HSM role.
Possible Solutions
sudo usermod -G nfast kms
Failed to start server reported by cloudera-manager-installer.bin
"Failed to start server" reported by cloudera-manager-installer.bin. /var/log/cloudera-scm-server/cloudera-scm-server.logcontains a message beginning Caused by: java.lang.ClassNotFoundException: com.mysql.jdbc.Driver...
Possible Reasons
You might have SELinux enabled.
Possible Solutions
Disable SELinux by running sudo setenforce 0 on the Cloudera Manager Server host. To disable it permanently, edit /etc/selinux/config.
Installation interrupted and installer does not restart
Installation interrupted and installer does not restart.
Possible Reasons
You need to do some manual cleanup.
Possible Solutions
Cloudera Manager Server fails to start with MySQL
Cloudera Manager Server fails to start and the Server is configured to use a MySQL database to store information about service configuration.
Possible Reasons
Tables ... have unsupported engine type ... . InnoDB is required.
Possible Solutions
Make sure that the InnoDB engine is configured, not the MyISAM engine. To check what engine your tables are using, run the following command from the MySQL shell: mysql> show table status;
For more information, see Install and Configure MySQL for Cloudera Software.
Agents fail to connect to Server
Agents fail to connect to Server. You get an Error 113 ('No route to host') in /var/log/cloudera-scm-agent/cloudera-scm-agent.log.
Possible Reasons
You might have SELinux or iptables enabled.
Possible Solutions
Check /var/log/cloudera-scm-server/cloudera-scm-server.log on the Server host and /var/log/cloudera-scm-agent/cloudera-scm-agent.log on the Agent hosts. Disable SELinux and iptables.
Cluster hosts do not appear
Some cluster hosts do not appear when you click Find Hosts in install or update wizard.
Possible Reasons
You might have network connectivity problems.
Possible Solutions
- Make sure all cluster hosts have SSH port 22 open.
- Check other common causes of loss of connectivity such as firewalls and interference from SELinux.
"Access denied" in install or update wizard
"Access denied" in install or update wizard during database configuration for Activity Monitor or Reports Manager.
Possible Reasons
Hostname mapping or permissions are not set up correctly.
Possible Solutions
- For hostname configuration, see Configure Network Names.
- For permissions, make sure the values you enter into the wizard match those you used when you configured the databases. The value you enter into the wizard as the database hostname
must match the value you entered for the hostname (if any) when you configured the database.
For example, if you had entered the following when you created the database
grant all on activity_monitor.* TO 'amon_user'@'myhost1.myco.com' IDENTIFIED BY 'amon_password';
the value you enter here for the database hostname must be myhost1.myco.com. If you did not specify a host, or used a wildcard to allow access from any host, you can enter either the fully qualified domain name (FQDN), or localhost. For example, if you entered
grant all on activity_monitor.* TO 'amon_user'@'%' IDENTIFIED BY 'amon_password';
the value you enter for the database hostname can be either the FQDN or localhost.
Databases fail to start.
Activity Monitor, Reports Manager, or Service Monitor databases fail to start.
Possible Reasons
MySQL binlog format problem.
Possible Solutions
Set binlog_format=mixed in /etc/my.cnf. For more information, see this MySQL bug report. See also Step 4: Install and Configure Databases.
Cloudera services fail to start
Cloudera services fail to start.
Possible Reasons
Java might not be installed or might be installed at a custom location.
Possible Solutions
See Configuring a Custom Java Home Location for more information on resolving this issue.
Activity Monitor displays a status of BAD
The Activity Monitor displays a status of BAD in the Cloudera Manager Admin Console. The log file contains the following message:
ERROR 1436 (HY000): Thread stack overrun: 7808 bytes used of a 131072 byte stack, and 128000 bytes needed. Use 'mysqld -O thread_stack=#' to specify a bigger stack.
Possible Reasons
The MySQL thread stack is too small.
Possible Solutions
- Update the thread_stack value in my.cnf to 256KB. The my.cnf file is normally located in /etc or /etc/mysql.
- Restart the mysql service: $ sudo service mysql restart
- Restart Activity Monitor.
Activity Monitor fails to start
The Activity Monitor fails to start. Logs contain the error read-committed isolation not safe for the statement binlog format.
Possible Reasons
The binlog_format is not set to mixed.
Possible Solutions
Modify the mysql.cnf file to include the entry for binlog format as specified in Install and Configure MySQL for Cloudera Software.
Attempts to reinstall lower version of Cloudera Manager fail
Attempts to reinstall lower versions of CDH or Cloudera Manager using yum fails.
Possible Reasons
It is possible to install, uninstall, and reinstall CDH and Cloudera Manager. In certain cases, this does not complete as expected. If you install Cloudera Manager 6 and CDH 6, then uninstall Cloudera Manager and CDH, and then attempt to install CDH 5 and Cloudera Manager 5, incorrect cached information might result in the installation of an incompatible version of the Oracle JDK.
Possible Solutions
Clear information in the yum cache:
- Connect to the CDH host.
- Execute either of the following commands:
yum --enablerepo='*' clean all
or
sudo rm -rf /var/cache/yum/cloudera*
- After clearing the cache, proceed with installation.
Create Hive Metastore Database Tables command fails
The Create Hive Metastore Database Tables command fails due to a problem with an escape string.
Possible Reasons
PostgreSQL versions 9 and higher require special configuration for Hive because of a backward-incompatible change in the default value of the standard_conforming_strings property. Versions up to PostgreSQL 9.0 defaulted to off, but starting with version 9.0 the default is on.
Possible Solutions
ALTER DATABASE <hive_db_name> SET standard_conforming_strings = off;
Oracle invalid identifier
If you are using an Oracle database and the Cloudera
tab displays "No data available" and there is an Oracle error about "invalid identifier" with the query containing the reference to dbms_crypto in the log.Possible Reasons
You have not granted execute permission to sys.dbms_crypto.
Possible Solutions
Run GRANT EXECUTE ON sys.dbms_crypto TO nav;, where nav is the user of the Navigator Audit Server database.
<< Secure Your Cluster | ©2016 Cloudera, Inc. All rights reserved | Uninstalling Cloudera Manager and Managed Software >> |
Terms and Conditions Privacy Policy |