Known Issues in Apache ZooKeeper
Learn about the known issues in ZooKeeper, the impact or changes to the functionality, and the workaround.
- OPSAPS-61188: Zookeeper start fails with custom user as contents inside /var/lib/zookeeper have "zookeeper" as owner instead of the custom user
- In Cloudera Manager the Process Username
for ZooKeeper can be changed from the default
zookeepervalue to any custom value. This configuration change in Cloudera Manager automatically changes the owner of the
var/lib/zookeeperfolder but keeps
zookeeperas the owner of any folders or files inside
var/lib/zookeeper, such as
version-2. As a result ZooKeeper fails to start because it needs to read the snapshots and txnlogs from the
var/lib/zookeeper/version-2folder when starting.
- Ensure that you changed the Process Username to a username that exists on the OS.
- Manually change the owner.
- Log in to the node.
- Recursively change the owner of
- Zookeeper-client does not use ZooKeeper TLS/SSL automatically
- The command-line tool ‘zookeeper-client’ is installed to all Cloudera Nodes and it can be used to start the default Java command line ZooKeeper client. However even when ZooKeeper TLS/SSL is enabled, the zookeeper-client command connects to localhost:2181, without using TLS/SSL.
- Manually configure the 2182 port, when zookeeper-client connects to a ZooKeeper
cluster.The following is an example of connecting to a specific three-node ZooKeeper
cluster using TLS/SSL:
CLIENT_JVMFLAGS="-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty -Dzookeeper.ssl.keyStore.location=<path to your configured keystore> -Dzookeeper.ssl.keyStore.password=<the password you configured for the keystore> -Dzookeeper.ssl.trustStore.location=<path to your configured truststore> -Dzookeeper.ssl.trustStore.password=<the password you configured for the truststore> -Dzookeeper.client.secure=true" zookeeper-client -server <your.zookeeper.server-1>:2182,<your.zookeeper.server-2>:2182,<your.zookeeper.server-3>:2182