About bgooley

bgooley · ‎07-09-2018

You may want to add DEBUG to Service Monitor and try the query again. *maybe* some clues may come to light, but I hate to say I doubt it.

bgooley · ‎07-09-2018

@Prav, I used the same one you used: /api/v17/clusters/Cluster 1/services/IMPALA-1/impalaQueries?from=2018-08-01T17:04:32.776Z works fine on my small test cluster

bgooley · ‎07-09-2018

@Prav, I am not an expert in these queries, but ISO 8601 format is what is used (like 2018-07-09T17:04:32.776Z). If you have a lot of impala queries in this cluster you may need to specify a "to" time as well. I'm not sure why, when you specified the time liste din the warning, the same warning appeared... that does seem strange. Do you see queries listed in the CM UI? maybe try finding one query and try making the "from" and "to" in the API query encompass one or two queries that are displayed in CM.

bgooley · ‎07-09-2018

@prabhat10, The log lines provided are not errors and probably don't have anything to do with the server not starting. Some things to review to identify why the server is not starting: (1) The stdout.log and stderr.log files for the Hbase Thrift server In Cloudera Manager, go to Hbase --> Instances --> Hbase Thrift Server When in the Hbase Thrift Server page, click the "Log Files" drop-down and choose stout.log and stderr.log. Generally, the last lines of the stderr.log file will indicate if the supervisor was able to start up the process or not. (2) If there are no errors at the bottom of the stderr.log, then it is likely the Hbase Thrift Server started up but then failed for some reason. In this case, you want to have a look at the Hbase Thrift Server logs. You can also view "Role Log" in the "Log Files" drop down in Cloudera Manager to view the role log. It may be easier to read via the command line, though. If you can, ssh to the host where the Hbase Thrift Server should be running and navigate to /var/log/hbase. You will see your HBASETHRIFTSERVER log file(s) there and you can review the logs for review. (3) What is the real problem you see? What observations tell you that the server is having a problem?

bgooley · ‎07-06-2018

@Prav, This is an internal limit on how searches are done that restricts "scanning" across partitions (based on time). When you see this message, generally you can take the time in the warning and then use that to formulate a new query specifying that as the start time.

bgooley · ‎07-06-2018

@balusu, Yeah, I'm not sure if supergroup mapping will work if the group has the domain on it. I can't confirm it won't, but if you changed the group name, restarted HFDS, and still didn't have group access, that does indicate the config may not work. You may try running "hdfs groups <user>" to see if that command "sees" your groups....

bgooley · ‎07-06-2018

@balusu, auth_to_local is used to map a user's principal to a unix name only. It is not used for anything group-oriented. By default, only the "hdfs" user is a superuser so it is the only user who can perform "chown" operations. If you want to make other users superusers, you can do so by defining which group will be the "supergroup" and which users belong to it. The group must be accessible via the OS (getent group supergroup). The default name for the supergroup is "supergroup" In cloudera Manager you can see this configuration in HDFS --> Configuration --> Superuser Group is there a reason you are trying to attach the "@domain" onto the group name? I would recommend adding a group named "supergroup" if you don't need to change the default. Then add sbalusu as a member. Note this has nothing to do with Kerberos at all at this point... this is all group mapping for hadoop.

bgooley · ‎07-06-2018

@Szczechla, Thank you for the information. (1) yes, .flood permissions are fine (2) You have many parcel urls in your Parcels configuraiton that do not support el7. You can remove the parcel urls that you do not need: Impala CDH4 Spark Solr To remove the parcel URLs, go to Administration --> Settings --> Parcels. Once these are removed, Cloudera Manager will no longer try to find parcels for your el7 hosts. (3) Yes, if Cloudera Manager shows that CDH 5.9.3 parcel is in Downloaded state, then you can remove any 5.9.3 files or directories in /opt/cloudera/parcels and /opt/cloudera/parcel-cache and /opt/cloudera/parcels/.flood Be careful you are removing only 5.9.3 though (4) Yes, indeed something very odd happened here, so I agree that cleaning up and trying again is the right path to success. (5) There is no benefit in deleting the parcel (from parcel-repo) but also no harm in it (6) You are correct: Activiation adds the CDH link to the activated parcel and the "active" parcel is registered in Cloudera Manager so that it will ensure all agents have activated the parcel, too. Lastly, if you clean up and the same problem happens again, let's take a closer look at the agent logs on the hosts where zookeeper won't start. There may be clues. good luck!

bgooley · ‎07-05-2018

No problem. I as long as you have a reasonable solution to address the issue, that's all good. 🙂

bgooley · ‎07-05-2018

@VijayM, You can leverage the following in Cloudera Manager's Administration --> Settings --> External Authentication configuration: Authentication Backend Order Choose: External Only (with emergency Administrator access) or External Only (without emergency Administrator access) If you still want the ability to use a local Full Administrator or User Administrator in the event your something went wrong with the LDAP host, then you could set it to "External Only (with emergency Administrator access)". Otherwise, set it to "External Only (without emergency Administrator access)" to allow NO local authentication. I am not sure what you mean by "disable" so if the above does not help, please clarify what disable means to you. -Ben

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: CM API: Maximum number of requests

Re: CM API: Maximum number of requests

Re: CM API: Maximum number of requests

Re: My Hbase Thrift Server is not Running.

Re: CM API: Maximum number of requests

Re: Kerberos ticket error:No rules applied to hdfs...

Re: Kerberos ticket error:No rules applied to hdfs...

Re: Problem with upgrade from 5.9.0 to 5.93 - addi...

Re: Kerberos ticket error:No rules applied to hdfs...

Re: Disable admin Login in Cloudera Manager