About bgooley

bgooley · ‎07-26-2017

Hi @MikeJones, I'm not sure what you are saying. Either you have Kerberos authentication enabled in a cluster or you don't. In order to use BDR HDFS replication, you need to have Kerberos enabled on both clusters or not enabled in both clusters. For information about how BDR replication supports replicating between clusters in different realms, see: https://www.cloudera.com/documentation/enterprise/latest/topics/cm_bdr_replication_and_kerberos.html -Ben

bgooley · ‎07-10-2017

@AllenGosta, What you have provided is the hs_err log from a JVM crash. It shows that the JVM essentially wanted more memory and the OS could not grant it: # Out of Memory Error (gcTaskThread.cpp:48), pid=2670, tid=0x00007f4421eac700 Without context, it is hard to say, but I'd start with the basics and make sure that you have not overcommitted memory on the host, look at Cloudera Manager's charts for the host where the problem happened (to view memory usage, etc.) Also, consider what was occurring at the time of the crash... were you doing something in particular? Where queries or jobs running? Do some web searches for this crash to find suggestions, too. These crashes are not specific to Cloudera Manager, CDH, etc.; rather, it is JVM crash information. Regards, Ben

bgooley · ‎07-09-2017

@Yoavb, Based on the stack, the user running the process does not have permission to bind to port 514 since it is a privileged port. Try using a port higher than 1024. Also web search for "privileged ports" for some background info if needed. Ben

bgooley · ‎07-06-2017

@HMC By default, CDH Hue has no superuser user/pass since the backend is "desktop.auth.backend.AllowFirstUserDjangoBackend" by default. Whatever user and password you enter on first login will be the superuser. If your authentication is failing, it means that someone already logged in with a username and password. This page can help you change a password or create a new superuser (assuming you are still using desktop.auth.backend.AllowFirstUserDjangoBackend) http://gethue.com/password-management-in-hue/ -Ben

bgooley · ‎07-05-2017

@JeffKubina Oops, that was overkill... forgot that supervisorctl status output has the PID column already... So, you can run: /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf status The PID will be the 4th column. -Ben

bgooley · ‎07-05-2017

@JeffKubina, While there are a number of ways to get the PID (like ps aux |grep ....), this is one I just thought up: /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf pid `ls -lrt /var/run/cloudera-scm-agent/process/ | awk '{print $9}' |grep DATANODE| tail -1` What it does is run supervisor's client using the Cloudera Manager sueprvisord.conf file to retrieve a pid file. The backticks execute a command to get the most recent process directory to pass into the "pid" command of supervisorctl. You can see the process names and statuses using the following: /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf status -Ben

bgooley · ‎07-05-2017

@JeffKubina, Since the supervisor starts CM managed processes, there is no PID file for the processes it starts. Short answer: there is no PID file. -Ben

bgooley · ‎05-15-2017

Hi @AntoineH, The error means that Hue connected to xxxx30.server.lan but the certificate that was returned had a subject CN or Subject Alternative Name that did not match. In fact, the certificate said it was for xxxx29.server.lan. It is common for TLS clients to check that the hostname in the server certificate matches the hostname of the host to which they are connecting to help validate that they are connecting to the correct server. You have 2 options to correct this situation: (1) Recommended: Install a correct certificate on xxxx30.server.lan that has a Subject Alternative Name or subject CN value that matches the hostname. (2) If you accept the security risk, you can disable Hue's peer certificate checks (also disables certificate signer trust validation), you can set the following in Hue's configuration: [beeswax] [[ssl]] validate=false Regards, Ben

bgooley · ‎05-08-2017

@frankenstein, "server DNS address could not be found." indicates that your configured DNS servers on the browser host cannot resolve your hostname. Make sure gke-hadoop-ubuntu-default-pool-78514257-626p.c.platform-services.internal can be resolved to an IP address on your browser host.

bgooley · ‎04-27-2017

One more lastly: "Exception thrown by the agent" is not from Cloudera's Agent; rather it is the RMI Agent I believe and a web search confirms that the error you see is when the RMI port is taken

Online	Offline
Last Visited	‎04-24-2020 01:13 PM

Member Since	‎04-22-2014 02:47 PM
Last Visited	‎04-24-2020 01:13 PM
Posts	1,218
Kudos received	339

Cloudera Community

Re: ALL hadoop-mapreduce-examples.jar fail cdh6

Re: YARN NodeManagers failed to start with permiss...

Re: Disable admin Login in Cloudera Manager

Re: Kerberos not authenticating from Hadoop Gatewa...

Re: Sqoop connection to Kerberos authenticated RDB...

Re: BDR Replication between secure and non secure ...

Re: Error with memory

Re: Using flume to upload syslog into hdfs on clod...

Re: hue default password after new cluster install

Re: For CDH 5.7.0 what is the full path to an HDFS...

Re: For CDH 5.7.0 what is the full path to an HDFS...

Re: For CDH 5.7.0 what is the full path to an HDFS...

Re: Configuring Hue SSL to connect to Hive with Ke...

Re: Hub Web UI doesn't work

Re: Issue while adding zookeeper