Cloudera Docs

Known Issues in Cloudera Manager 7.7.3

Known issues in Cloudera Manager 7.7.3

OPSAPS-65691: Cloudera Manager upgrade from 7.6.7 version fails with an ApiException error

While upgrading Cloudera Manager from Cloudera Manager 7.6.7 to Cloudera Manager 7.7.3, the upgrade failed with the following error message: ApiException: Expected boolean. Got END_OBJECT (error 400).

The following error is also logged in Cloudera Manager server log: scm-web-198:com.cloudera.server.web.cmf.home.SystemHealth: HealthInfo Exception:Exception occurred inside setter of com.cloudera.cmf.model.DbProcess.specialFileInfoForDb

Upgrade to the Cloudera Manager 7.7.3 CHF4 or later versions where this issue is fixed.

OPSAPS-68452: Azul Open JDK 8 and 11 are not supported with Cloudera Manager

Azul Open JDK 8 and 11 are not supported with Cloudera Manager. To use Azul Open JDK 8 or 11 for Cloudera Manager RPM/DEBs, you must manually create a symlink between the Zulu JDK installation path and the default JDK path.

After installing Azul Open JDK8 or 11, you must run the following commands on all the hosts in the cluster:
Azul Open JDK 8
RHEL or SLES
# sudo ln -s /usr/lib/jvm/java-8-zulu-openjdk-jdk /usr/lib/jvm/java-8-openjdk
Ubuntu or Debian
# sudo ln -s /usr/lib/jvm/zulu-8-amd64 /usr/lib/jvm/java-8-openjdk
Azul Open JDK 11
For DEBs only
# sudo ln -s /usr/lib/jvm/zulu-11-amd64 /usr/lib/jvm/java-11
OPSAPS-67152: Cloudera Manager does not allow you to update some configuration parameters.

Cloudera Manager does not allow you to set to "0" for the dfs_access_time_precision and dfs_namenode_accesstime_precision configuration parameters.

You will not be able to update dfs_access_time_precision and dfs_namenode_accesstime_precision to "0". If you try to enter "0" in these configuration input fields, then the field gets cleared off and results in a validation error: This field is required.

To fix this issue, perform the workaround steps as mentioned in the KB article.

If you need any guidance during this process, contact Cloudera support.

Cloudera bug: OPSAPS-59764: Memory leak in the Cloudera Manager agent while downloading the parcels.

When using the M2Crpyto library in the Cloudera Manager agent to download parcels causes a memory leak.

The Cloudera Manager server requires parcels to install a cluster. If any of the URLs of parcels are modified, then the server provides information to all the Cloudera Manager agent processes that are installed on each cluster host.

The Cloudera Manager agent then starts checking for updates regularly by downloading the manifest file that is available under each of the URLs. However, if the URL is invalid or not reachable to download the parcel, then the Cloudera Manager agent shows a 404 error message and the memory of the Cloudera Manager agent process increases due to a memory leak in the file downloader code of the agent.

To prevent this memory leak, ensure all URLs of parcels in Cloudera Manager are reachable. To achieve this, delete all unused and unreachable parcels from the Cloudera Manager parcels page.

Cloudera bug: OPSAPS-66235 Diagnostic bundle missing host statistics
Diagnostic bundles do not include host statistics. The following error message displays in the command output: Collect Host Statistics sub-command has failed.
None
Cloudera bug: OPSAPS-65243 Diagnostic data collection for YARN fails
Selecting Collect Diagnostic Data from the YARN > Applications page fails to generate the diagnostic data.
None
Cloudera bug: OPSAPS-65269 Hosts report no heartbeat after upgrading to Cloudera Manager 7.7.3 and then rolling back to Cloudera Manager 7.7.1.
After upgrading Cloudera Manager 7.7.1 to 7.7.3 and then rolling back to 7.7.1 Cloudera Manager may report no heartbeat from one or more hosts and also reports bad health for services.
Reboot the hosts.
Cloudera bug: OPSAPS-65189: Accessing Cloudera Manager through Knox displays the following error:

Bad Message 431 reason: Request Header Fields Too Large

Workaround: Modify the Cloudera Manager Server configuration /etc/default/cloudera-scm-server file to increase the header size from 8 KB, which is the default value, to 65 KB in the Java options as shown below:
export CMF_JAVA_OPTS="...existing options...
-Dcom.cloudera.server.cmf.WebServerImpl.HTTP_HEADER_SIZE_BYTES=65536
-Dcom.cloudera.server.cmf.WebServerImpl.HTTPS_HEADER_SIZE_BYTES=65536"
OPSAPS-65213: Ending the maintenance mode for a commissioned host with either an Ozone DataNode role or a Kafka Broker role running on it, might result in an error.

You may see the following error if you end the maintenance mode for Ozone and Kafka services from Cloudera Manager when the roles are not decommissioned on the host.

Execute command Recommission and Start on service OZONE-1
Failed to execute command Recommission and Start on service OZONE-1
Recommission and Start
Command Recommission and Start is not currently available for execution.
To resolve this issue, use the API support feature to take the host out of maintenance mode.
  1. Log into Cloudera Manager as an Administrator.
  2. Go to Hosts > All Hosts.
  3. Select the host for which you need to end the maintenance mode from the available list and click the link to open the host details page.
  4. Copy the Host ID from the Details section.
  5. Go to Support > API Explorer.
  6. Locate and click the /hosts/{hostId}/commands/exitMaintenanceMode endpoint for HostsResource API to view the API parameters.
  7. Click Try it out.
  8. Enter the ID of your host in the hostId field.
  9. Click Execute.
  10. Verify that the maintenance mode status is cleared for the host by checking the Server response code.

    The operation is successful if the API response code is 200.

If you need any guidance during this process, contact Cloudera support for further assistance.

Cloudera bug: OPSAPS-65443 Phoenix requires Python 2.7
Phoenix requires Python 2.7 in order to run in Cloudera Manager 7.7.3 GA, CHF 1, and CHF 2.
Fix will be available in Cloudera Manager 7.7.3 CHF3.
OPSAPS-65104
Replication Manager does not work as expected when you upgrade from Cloudera Manager version 7.6.7 CHF2 to any Cloudera Manager version between 7.7.1 and 7.7.1 CHF13. If there were any Hive replication policies before the upgrade, Replication Manager does not respond after the upgrade.
If you are using Hive replication policies in Cloudera Manager 7.6.7 CHF2 or higher versions, you must only upgrade to Cloudera Manager 7.7.1 CHF14 version or higher.