Hi @Michael Bronson All services logs can be found at the location mentioned in the yarn-env.sh (can be found under Hadoop Conf files, usually /etc/hadoop/conf/) on the respective nodes. Hence please check location mentioned in yarn-env.sh on the master02 machine. Once we check the logs, it will be easier to figure out the exact reason for failure. Example yarn-env.sh export YARN_LOG_DIR=/grid/0/log/yarn/ ... View more

@Michael Bronson When we delete a service from ambari via Ambari UI then immediately after service deletion the Ambari UI reloads the page and then you won't see the deleted services in the ambari UI on the left panel. However when we delete services via ambari API then it does not involve the Ambari UI invocation rather it simply invokes the back end APIs that are responsible for deleting the Service details from the ambari DB directly and hence the ambari UI will still show the Deleted Service present there. . So after deleting the service using ambari APIs you will need to refresh the ambari UI (a hard browser refresh), which will make the ambari UI to reload the service list and then you should not see the deleted service there. Sometimes it also happens that some browsers (like Internet Explorer does a caching of the browser contents) caches the UI data so in that you might have to either disable the browser cache or doa hard refresh of the browser or reopen the browser after clearing the ambari UI cache from browser. You do not need to restart the ambari server, rather you will need to just refresh the browser or clear the browser cache and reopen it. . Unfortunately it is not possible to refresh the Ambari UI using the Rest API calls (or using any CLI calls). ... View more

f you don't run the filesystem checker, the apparent corruption in the filesystem may get worse. Unchecked, this can lead to data corruption or at the unlikely worst destruction of the filesystem. During the filesystem check, file structures within the filesystem will be checked, and if necessary repaired. The repair takes no account of content; it's all about making sure the filesystem is self-consistent. If you run e2fsck -y /dev/sdc you have no opportunity to validate the corrections being applied. On the other hand if you run e2fsck -n /dev/sdc you can see what would happen without it actually being applied, and if you run e2fsck /dev/sdc you will be asked each time a significant correction needs to be applied. In summary If you ignore the warning and do nothing, over time you may lose your data If you run with -y you have no option to review the potentially destructive changes, and you may lose your data If you run with -n you will not fix any errors, and over time may lose your data, but you will get to review the set of changes that would be made If you run with no special flag you will be prompted to fix relevant errors, and you can decide for each whether you are going to need direct professional assistance Recommendation Run e2fsck -n /dev/sdc to review the errors Decide whether this merits a subsequent e2fsck /dev/sdc (or possibly e2fsck -y /dev/sdc ) or whether you would prefer to obtain direct professional assistance ... View more

@Michael Bronson There are some limited predefined alerts available in terms of disk checking in ambari. However ambari allows users to register their own custom alert definitions to fulfill their need. Following is an article that explains how we can register our own custom ambari alert and register it with Ambari to get custom alerts: https://community.hortonworks.com/articles/38149/how-to-create-and-register-custom-ambari-alerts.html . Once the alert is setup and working we can either Setup Email Notification (OR) SNMP notification based on our requierment as described in : https://community.hortonworks.com/articles/40361/how-to-troubleshoot-ambari-alerts-notification.html https://docs.hortonworks.com/HDPDocuments/Ambari-2.6.0.0/bk_ambari-operations/content/creating_or_editing_notifications.html . ... View more