Support Questions
Find answers, ask questions, and share your expertise
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Who agreed with this solution

Re: Incorrect symlinks being created by cloudera-scm-agent


I have found the solution to the problem.


Cloudera-scm-agent runs a tool called /usr/lib64/cmf/service/common/ to generate /etc/alternatives and symlinks to /usr/bin/*.  This bash script executes update-alternatives based on the PARCELS_DIR and PARCEL_DIRNAME variables. There are files in /var/lib/alternatives/ which seem to be used as overrides for the update-alternatives tool.  Regardless of what you give update-alternatives, if there is a file in /var/lib/alternatives for that same alternative name it will use the information from the /var/lib/alternatives file.


For some reason the /var/lib/alternatives files for cloudera have two entries in them, one for the old parcel and one for the new parcel.  This may have happened by reinstalling without deactivating the old cluster/parcel first.


# cat /var/lib/alternatives/sqoop



When I remove the /var/lib/alternatives/sqoop-import file and restart cloudera-scm-agent the proper symlink is created.


# ls -lsa /etc/alternatives/sqoop-import
4 lrwxrwxrwx 1 root root 64 Sep 3 19:00 /etc/alternatives/sqoop-import -> /opt/cloudera/parcels/CDH-5.1.2-1.cdh5.1.2.p0.3/bin/sqoop-import


So, in closing, it may be neccessary to remove all cloudera related /var/lib/alternatives/ files after a botched install if you do not deactivate the parcel prior to reinstall.


# grep -l cloudera /var/lib/alternatives/*



View solution in original post

Who agreed with this solution