Bug 1440148

[07:47:19] <Skinny> I removed the rhel7_config function to test 
[07:47:25] <Skinny> the only error remaining is :  /usr/lib/x86_64-linux-gnu/ganesha/ganesha-ha.sh: Syntax error: redirection unexpected
[07:47:32] <Skinny> around line 242

<Skinny> I think I found it
<Skinny> you have 1 min to confirm my toughts ?
<Skinny> running the ganesha-ha.sh script from the ubuntu command line manually will run just fine (within bash)
<Skinny> however from within the glusterd deamon, the script is executed with a 'sh -c' call
<Skinny> which will override the used shell
<Skinny> the default shell on ubuntu is dash
<Skinny> and that doesnt have the <<< operator
<Skinny> used in the scripts (for logging)
<Skinny> that's the line failing with the 'redirection' error
<kkeithley> but ganesha.ha has shebang /bin/bash
<Skinny> http://stackoverflow.com/a/2462357
<glusterbot> Title: ubuntu - Bash: Syntax error: redirection unexpected - Stack Overflow (at stackoverflow.com)
<Skinny> read that answer (3th comment)
<Skinny> sh 'script' will use 'sh' instead of the shell in the file

<Skinny> resetting ubuntu to use bash at the default shell
<Skinny> fixes this error
<Skinny> just tested it
<Skinny> on to the next one : '[2017-04-07 12:05:01.381485] E [MSGID: 106471] [glusterd-ganesha.c:159:manage_service] 0-management: Could not start NFS-Ganesha.Service manager for distro not recognized.'
--> nishanth (nthomas@nat/redhat/x-ufxtckzgtoeotfuu) has joined #gluster
<Skinny> fixed by (for now symlinking /bin/systemctl to /usr/bin/systemctl)
<Skinny> the locations checked in 'manage_service' dont look in the ubuntu location which is /bin/systemctl

also the 'manage_service' function in \xlators\mgmt\glusterd\src\glusterd-ganesha.c doesn't check the default ubuntu location for systemctl which is /bin/systemctl (instead of /usr/bin/systemctl).

I worked around this by creating a symlink

(In reply to Mark Gerrits from comment #4)
> also the 'manage_service' function in
> \xlators\mgmt\glusterd\src\glusterd-ganesha.c doesn't check the default
> ubuntu location for systemctl which is /bin/systemctl (instead of
> /usr/bin/systemctl).
> 
> I worked around this by creating a symlink

someone beat me to it :)

REVIEW: https://review.gluster.org/17013 (common-ha: fixes for Debian-based systems) posted (#1) for review on release-3.10 by Kaleb KEITHLEY (kkeithle)

REVIEW: https://review.gluster.org/17013 (common-ha: fixes for Debian-based systems) posted (#2) for review on release-3.10 by Kaleb KEITHLEY (kkeithle)

COMMIT: https://review.gluster.org/17013 committed in release-3.10 by Shyamsundar Ranganathan (srangana) 
------
commit e93e89b2e46033efa22447943269000c85588254
Author: Kaleb S. KEITHLEY <kkeithle>
Date:   Fri Apr 7 09:09:29 2017 -0400

    common-ha: fixes for Debian-based systems
    
    1) Debian-based systems don't have /usr/libexec/... and there is
    a hard-coded invocation of /usr/libexec/ganesha/ganesha-ha.sh within
    ganesha-ha.sh itself.
    Fix: save $0 and use it instead for further invocations of self.
    
    2) default shell is /bin/dash (not /bin/bash). Various runner_run()
    invocations for ganesha used what amounts to
      exec("sh /usr/$libexec/ganesha/ganesha-ha.sh ...);
    which executes the script using the default shell, but there are
    some bash-specific idioms that don't work if the shell is dash.
    Fix: change to exec("/usr/$libexec/ganesha/ganesha-ha.sh ...); so that
    the shebang forces the use of /bin/bash
    
    3) Fedora and RHEL7 have merged /bin/ and /usr/bin, /bin is a symlink
    to /usr/bin. Debian-based systems are not merged, and systemd systems
    have /bin/systemctl. The logic to find .../bin/systemctl is backwards.
    If the logic looks for /usr/bin/systemctl it will not find it on
    Debian-based systems; if it looks for /bin/systemctl it will find it
    on Fedora and RHEL by virtue of the symlink. (RHEL6 and others will
    find their respective init regardless.)
    Fix: change the logic to look for /bin/systemctl instead.
    
    4) The logic for deciding to run systemctl (or not) is a bit silly.
    Fix: simply invoke the found method via the function pointer in the
    table.
    
    Change-Id: I33681b296a73aebb078bda6ac0d3a1d3b9770a21
    BUG: 1440148
    Signed-off-by: Kaleb S. KEITHLEY <kkeithle>
    Reviewed-on: https://review.gluster.org/17013
    Smoke: Gluster Build System <jenkins.org>
    Reviewed-by: Niels de Vos <ndevos>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.org>
    Reviewed-by: jiffin tony Thottan <jthottan>

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.10.2, please open a new bug report.