FAQ
I created a yarn service manually to test the installation (No HA). After
that the service yarn was deleted.

A new yarn service by name yarn1 was created (HA), all is fine, un till I
ran a wordcount job from the CLI of one of the hadoop servers (hadoop jar
Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
/user/wordcount/output). The job never starts and keeps trying the connect
to the fist yarn instance which is in standby.

Looking into client config that is created under /etc/hadoop it was still
pointing to the old yarn instance which was deleted and not to yarn1
instance.

I then manually rewired the symlink of hadoop-conf to
/etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
successfully and i was able to toggle between standby and active RM.

But, the problem now is that when ever I deploy client configuration or run
my cloudera install script that does the configuration deployment, it
reverts the symlink to the yarn instance and not yarn1.

Can anyone help?

cd /etc/hadoop
lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
/etc/alternatives/hadoop-conf
drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

cd /etc/alternatives/hadoop-conf
lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
/opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
/opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
/etc/hadoop/conf.cloudera.yarn*
lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
/opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
/opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

Regards,
Vikram

To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.

Search Discussions

  • Darren Lo at Apr 24, 2014 at 3:02 pm
    Hi vikram,

    Whenever you delete a service, CM does not clean up the client configs in
    /etc/. You may need to run the alternatives command to remove the old link
    on each host.

    Example:
    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
      link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.OLD_YARN - priority 92
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.OLD_YARN.

    alternatives --remove hadoop-conf /etc/hadoop/conf.cloudera.OLD_YARN

    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
      link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.YARN-1


    Make sure you do this on all hosts.

    Thanks,
    Darren

    On Wed, Apr 23, 2014 at 10:04 PM, Vikram Bajaj wrote:

    I created a yarn service manually to test the installation (No HA). After
    that the service yarn was deleted.

    A new yarn service by name yarn1 was created (HA), all is fine, un till I
    ran a wordcount job from the CLI of one of the hadoop servers (hadoop jar
    Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
    /user/wordcount/output). The job never starts and keeps trying the connect
    to the fist yarn instance which is in standby.

    Looking into client config that is created under /etc/hadoop it was still
    pointing to the old yarn instance which was deleted and not to yarn1
    instance.

    I then manually rewired the symlink of hadoop-conf to
    /etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
    successfully and i was able to toggle between standby and active RM.

    But, the problem now is that when ever I deploy client configuration or
    run my cloudera install script that does the configuration deployment, it
    reverts the symlink to the yarn instance and not yarn1.

    Can anyone help?

    cd /etc/hadoop
    lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
    /etc/alternatives/hadoop-conf
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
    drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
    drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

    cd /etc/alternatives/hadoop-conf
    lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
    lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
    lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
    /etc/hadoop/conf.cloudera.yarn*
    lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
    lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

    Regards,
    Vikram

    To unsubscribe from this group and stop receiving emails from it, send an
    email to scm-users+unsubscribe@cloudera.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.
  • Vikram Bajaj at Apr 24, 2014 at 6:38 pm
    Thanks Darren, that does resolve the issue. I guess it would be helpful if
    this can be part of CM documentation :)

    On Thu, Apr 24, 2014 at 8:02 AM, Darren Lo wrote:

    Hi vikram,

    Whenever you delete a service, CM does not clean up the client configs in
    /etc/. You may need to run the alternatives command to remove the old link
    on each host.

    Example:
    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.OLD_YARN - priority 92
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.OLD_YARN.

    alternatives --remove hadoop-conf /etc/hadoop/conf.cloudera.OLD_YARN

    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.YARN-1


    Make sure you do this on all hosts.

    Thanks,
    Darren

    On Wed, Apr 23, 2014 at 10:04 PM, Vikram Bajaj wrote:

    I created a yarn service manually to test the installation (No HA). After
    that the service yarn was deleted.

    A new yarn service by name yarn1 was created (HA), all is fine, un till I
    ran a wordcount job from the CLI of one of the hadoop servers (hadoop jar
    Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
    /user/wordcount/output). The job never starts and keeps trying the connect
    to the fist yarn instance which is in standby.

    Looking into client config that is created under /etc/hadoop it was still
    pointing to the old yarn instance which was deleted and not to yarn1
    instance.

    I then manually rewired the symlink of hadoop-conf to
    /etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
    successfully and i was able to toggle between standby and active RM.

    But, the problem now is that when ever I deploy client configuration or
    run my cloudera install script that does the configuration deployment, it
    reverts the symlink to the yarn instance and not yarn1.

    Can anyone help?

    cd /etc/hadoop
    lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
    /etc/alternatives/hadoop-conf
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
    drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
    drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

    cd /etc/alternatives/hadoop-conf
    lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
    lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
    lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
    /etc/hadoop/conf.cloudera.yarn*
    lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
    lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

    Regards,
    Vikram

    To unsubscribe from this group and stop receiving emails from it, send
    an email to scm-users+unsubscribe@cloudera.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.
  • Darren Lo at Apr 24, 2014 at 6:36 pm
    We actually did document it, though it could probably be improved.

    The page for deleting a service mentions this:
    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Managing-Clusters/cm5mc_delete_service.html

    We also mention it in known issues, though it suggests the easier, but less
    clean way of fixing this issue:
    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Release-Notes/cm5rn_known_issues.html

    Thanks,
    Darren

    On Thu, Apr 24, 2014 at 11:31 AM, Vikram Bajaj wrote:

    Thanks Darren, that does resolve the issue. I guess it would be helpful if
    this can be part of CM documentation :)

    On Thu, Apr 24, 2014 at 8:02 AM, Darren Lo wrote:

    Hi vikram,

    Whenever you delete a service, CM does not clean up the client configs in
    /etc/. You may need to run the alternatives command to remove the old link
    on each host.

    Example:
    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.OLD_YARN - priority 92
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.OLD_YARN.

    alternatives --remove hadoop-conf /etc/hadoop/conf.cloudera.OLD_YARN

    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.YARN-1


    Make sure you do this on all hosts.

    Thanks,
    Darren

    On Wed, Apr 23, 2014 at 10:04 PM, Vikram Bajaj wrote:

    I created a yarn service manually to test the installation (No HA).
    After that the service yarn was deleted.

    A new yarn service by name yarn1 was created (HA), all is fine, un till
    I ran a wordcount job from the CLI of one of the hadoop servers (hadoop jar
    Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
    /user/wordcount/output). The job never starts and keeps trying the connect
    to the fist yarn instance which is in standby.

    Looking into client config that is created under /etc/hadoop it was
    still pointing to the old yarn instance which was deleted and not to yarn1
    instance.

    I then manually rewired the symlink of hadoop-conf to
    /etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
    successfully and i was able to toggle between standby and active RM.

    But, the problem now is that when ever I deploy client configuration or
    run my cloudera install script that does the configuration deployment, it
    reverts the symlink to the yarn instance and not yarn1.

    Can anyone help?

    cd /etc/hadoop
    lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
    /etc/alternatives/hadoop-conf
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
    drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
    drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

    cd /etc/alternatives/hadoop-conf
    lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
    lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
    lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
    /etc/hadoop/conf.cloudera.yarn*
    lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
    lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

    Regards,
    Vikram

    To unsubscribe from this group and stop receiving emails from it, send
    an email to scm-users+unsubscribe@cloudera.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.
  • Vikram Bajaj at Apr 24, 2014 at 7:17 pm
    Yes, it is well documented, my bad! Should have searched a bit more.

    Appreciate your response!

    On Thu, Apr 24, 2014 at 11:36 AM, Darren Lo wrote:

    We actually did document it, though it could probably be improved.

    The page for deleting a service mentions this:

    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Managing-Clusters/cm5mc_delete_service.html

    We also mention it in known issues, though it suggests the easier, but
    less clean way of fixing this issue:

    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Release-Notes/cm5rn_known_issues.html

    Thanks,
    Darren

    On Thu, Apr 24, 2014 at 11:31 AM, Vikram Bajaj wrote:

    Thanks Darren, that does resolve the issue. I guess it would be helpful
    if this can be part of CM documentation :)

    On Thu, Apr 24, 2014 at 8:02 AM, Darren Lo wrote:

    Hi vikram,

    Whenever you delete a service, CM does not clean up the client configs
    in /etc/. You may need to run the alternatives command to remove the old
    link on each host.

    Example:
    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.OLD_YARN - priority 92
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.OLD_YARN.

    alternatives --remove hadoop-conf /etc/hadoop/conf.cloudera.OLD_YARN

    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.YARN-1


    Make sure you do this on all hosts.

    Thanks,
    Darren

    On Wed, Apr 23, 2014 at 10:04 PM, Vikram Bajaj wrote:

    I created a yarn service manually to test the installation (No HA).
    After that the service yarn was deleted.

    A new yarn service by name yarn1 was created (HA), all is fine, un till
    I ran a wordcount job from the CLI of one of the hadoop servers (hadoop jar
    Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
    /user/wordcount/output). The job never starts and keeps trying the connect
    to the fist yarn instance which is in standby.

    Looking into client config that is created under /etc/hadoop it was
    still pointing to the old yarn instance which was deleted and not to yarn1
    instance.

    I then manually rewired the symlink of hadoop-conf to
    /etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
    successfully and i was able to toggle between standby and active RM.

    But, the problem now is that when ever I deploy client configuration or
    run my cloudera install script that does the configuration deployment, it
    reverts the symlink to the yarn instance and not yarn1.

    Can anyone help?

    cd /etc/hadoop
    lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
    /etc/alternatives/hadoop-conf
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
    drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
    drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

    cd /etc/alternatives/hadoop-conf
    lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
    lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
    lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
    /etc/hadoop/conf.cloudera.yarn*
    lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
    lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

    Regards,
    Vikram

    To unsubscribe from this group and stop receiving emails from it, send
    an email to scm-users+unsubscribe@cloudera.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.
  • Darren Lo at Apr 24, 2014 at 7:40 pm
    Glad you got it working! This is an issue that has confused several people,
    so don't feel bad = )

    On Thu, Apr 24, 2014 at 12:17 PM, Vikram Bajaj wrote:

    Yes, it is well documented, my bad! Should have searched a bit more.

    Appreciate your response!

    On Thu, Apr 24, 2014 at 11:36 AM, Darren Lo wrote:

    We actually did document it, though it could probably be improved.

    The page for deleting a service mentions this:

    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Managing-Clusters/cm5mc_delete_service.html

    We also mention it in known issues, though it suggests the easier, but
    less clean way of fixing this issue:

    http://www.cloudera.com/content/cloudera-content/cloudera-docs/CM5/latest/Cloudera-Manager-Release-Notes/cm5rn_known_issues.html

    Thanks,
    Darren

    On Thu, Apr 24, 2014 at 11:31 AM, Vikram Bajaj wrote:

    Thanks Darren, that does resolve the issue. I guess it would be helpful
    if this can be part of CM documentation :)

    On Thu, Apr 24, 2014 at 8:02 AM, Darren Lo wrote:

    Hi vikram,

    Whenever you delete a service, CM does not clean up the client configs
    in /etc/. You may need to run the alternatives command to remove the old
    link on each host.

    Example:
    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.OLD_YARN - priority 92
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.OLD_YARN.

    alternatives --remove hadoop-conf /etc/hadoop/conf.cloudera.OLD_YARN

    alternatives --display hadoop-conf
    hadoop-conf - status is auto.
    link currently points to /etc/hadoop/conf.cloudera.YARN-1
    /etc/hadoop/conf.empty - priority 10
    /etc/hadoop/conf.cloudera.HDFS-1 - priority 90
    /etc/hadoop/conf.cloudera.YARN-1 - priority 92
    Current `best' version is /etc/hadoop/conf.cloudera.YARN-1


    Make sure you do this on all hosts.

    Thanks,
    Darren

    On Wed, Apr 23, 2014 at 10:04 PM, Vikram Bajaj wrote:

    I created a yarn service manually to test the installation (No HA).
    After that the service yarn was deleted.

    A new yarn service by name yarn1 was created (HA), all is fine, un
    till I ran a wordcount job from the CLI of one of the hadoop servers
    (hadoop jar Hadoop-WordCount/wordcount.jar WordCount /user/wordcount/input
    /user/wordcount/output). The job never starts and keeps trying the connect
    to the fist yarn instance which is in standby.

    Looking into client config that is created under /etc/hadoop it was
    still pointing to the old yarn instance which was deleted and not to yarn1
    instance.

    I then manually rewired the symlink of hadoop-conf to
    /etc/hadoop/conf.cloudera.yarn1 on all the hosts. After which the job ran
    successfully and i was able to toggle between standby and active RM.

    But, the problem now is that when ever I deploy client configuration
    or run my cloudera install script that does the configuration deployment,
    it reverts the symlink to the yarn instance and not yarn1.

    Can anyone help?

    cd /etc/hadoop
    lrwxrwxrwx. 1 root root 29 Apr 24 04:34 conf ->
    /etc/alternatives/hadoop-conf
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 conf.cloudera.hdfs1
    drwxr-xr-x. 2 root root 4096 Apr 17 18:32 conf.cloudera.mapreduce1
    drwxr-xr-x. 2 root root 4096 Apr 23 23:05* conf.cloudera.yarn*
    drwxr-xr-x. 2 root root 4096 Apr 24 04:33 *conf.cloudera.yarn1*

    cd /etc/alternatives/hadoop-conf
    lrwxrwxrwx. 1 root root 59 Apr 23 23:57 hadoop ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop
    lrwxrwxrwx. 1 root root 64 Apr 23 23:57 hadoop-0.20 ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-0.20
    lrwxrwxrwx. 1 root root 30 Apr 24 03:56 *hadoop-conf ->
    /etc/hadoop/conf.cloudera.yarn*
    lrwxrwxrwx. 1 root root 68 Apr 23 23:57 hadoop-fuse-dfs ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/bin/hadoop-fuse-dfs
    lrwxrwxrwx. 1 root root 77 Apr 23 23:57 hadoop-httpfs-conf ->
    /opt/cloudera/parcels/CDH-5.0.0-1.cdh5.0.0.p0.47/etc/hadoop-httpfs/conf.empty

    Regards,
    Vikram

    To unsubscribe from this group and stop receiving emails from it,
    send an email to scm-users+unsubscribe@cloudera.org.
    To unsubscribe from this group and stop receiving emails from it, send an email to scm-users+unsubscribe@cloudera.org.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupscm-users @
categorieshadoop
postedApr 24, '14 at 5:04a
activeApr 24, '14 at 7:40p
posts6
users2
websitecloudera.com
irc#hadoop

2 users in discussion

Darren Lo: 3 posts Vikram Bajaj: 3 posts

People

Translate

site design / logo © 2022 Grokbase