/server/cron.sh executes under /bin/sh and fails over "[[" tests

Discussion in 'Installation/Configuration' started by C_Duv, Jul 18, 2021 at 1:38 AM.

  1. C_Duv

    C_Duv New Member

    Hello,

    When debugging an issue with the acme.sh client (`acme.sh --issue` is called but `acme.sh --install-cert` is not) I finally noticed errors in the `/var/log/ispconfig/cron.log` file :

    Code:
    Sat 17 Jul 2021 11:08:10 PM UTC sh: 1: [[: not found
    Sat 17 Jul 2021 11:08:10 PM UTC sh: 1: 0: not found
    Sat 17 Jul 2021 11:08:10 PM UTC sh: 1: [[: not found
    
    They occurs when I enable SSL with Let's Encrypt for a website, the shell command created by PHP method `letsencrypt::get_acme_command()` is:

    Code:
    R=0 ; C=0 ; /root/.acme.sh/acme.sh --issue  -d example.com -d www.example.com -w /usr/local/ispconfig/interface/acme --always-force-new-domain-key --keylength 4096; R=$? ; if [[ $R -eq 0 || $R -eq 2 ]] ; then /root/.acme.
    sh/acme.sh --install-cert  -d example.com -d www.example.com --key-file '/var/www/clients/client1/web3/ssl/example.com-le.key' --fullchain-file '/var/www/clients/client1/web3/ssl/example.com-le.crt' --reloadcmd 'systemctl force-
    reload nginx.service' --log '/var/log/ispconfig/acme.log'; C=$? ; fi ; if [[ $C -eq 0 ]] ; then exit $R ; else exit $C  ; fi
    As this command uses "[[" / double brackets to check for `acme.sh --issue` exit code (`R` variable) I can understand the failure if ran with /bin/sh. By altering this command to output some debug info, I was able to confirm it gets executed by root user using /bin/sh shell.

    What I don't understand is why it runs as /bin/sh although root's shell is /bin/bash (confirmed by a `echo $SHELL` or `getent passwd root` from a classic root SSH shell)...

    Have I failed to set an ISPConfig setting right? I did not found anything about root's shell (except the part of the installer that actively set it to /bin/bash) in the documentation.

    (I am using ISPConfig v3.2.5 on Debian v10)

    Thanks for you help.
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Have you done that? The error message you show makes me suspect shell is dash, not bash.
    What shows
    Code:
    ls -lh /bin/sh /usr/bin/sh
     
    Th0m likes this.
  3. C_Duv

    C_Duv New Member

    It is dash indeed:
    Code:
    # ls -lh /bin/sh /usr/bin/sh
    lrwxrwxrwx 1 root root 4 Jun 29 12:31 /bin/sh -> dash
    lrwxrwxrwx 1 root root 4 Jun 29 12:31 /usr/bin/sh -> dash
    But why would /bin/sh be used in the first place? The shell for root user is not /bin/sh, it's /bin/bash
     
  4. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  5. C_Duv

    C_Duv New Member

    Thanks!
    It (`dpkg-reconfigure dash`) fixed it: no more errors in `/var/log/ispconfig/cron.log` file and the acme.sh client works.
    I'll have to double check my notes because I was pretty sure I had applied that part (and installation seemed to have been a complete success).

    I'll also have to, for my own culture, understand what are the implication of `dpkg-reconfigure dash` and how this changes the root shell for cronjobs.
     

Share This Page