0

I'm running a script provided by rehmatworks to install a LetsEncrypt certificate, which (in addition to the initial install) sets up a monthly cronjob to auto renew. Everything installs fine, however, the cron job is failing, and I can't seem to figure out why.

Here is the cron job (from root 'crontab -e'):

@monthly "sudo service nginx-sp stop && yes | letsencrypt --standalone renew &>/dev/null && service nginx-sp start && service nginx-sp reload"

Which fails with a not found error:

/bin/sh: 1: sudo service nginx-sp stop && yes | letsencrypt --standalone renew &>/dev/null && service nginx-sp start && service nginx-sp reload: not found

Running directly from the command line work fine, however:

sudo service nginx-sp stop && yes | letsencrypt --standalone renew &>/dev/null && service nginx-sp start && service nginx-sp reload

Any ideas why this works from command line, but not via cron?

  • Your first code sample shows an unbalanced quote; assuming it's actually balanced then the issue is likely that "command args" is not the same thing as command args i.e. the shell (sh) is seeing the quoted string as a single command rather than a command plus its arguments. Aside from that, remove sudo and run it from root's crontab if elevated permissions are required. – steeldriver May 7 '18 at 22:14
  • ... you will also need to change &>/dev/null (which is a bashism) to >/dev/null 2>&1 (or change the crontab's shell from /bin/sh to /bin/bash) – steeldriver May 7 '18 at 23:13
  • @steeldriver I think you got it. The trick is changing cron to 'SHELL=/bin/bash', and adding 'PATH=/sbin:/bin:/usr/sbin:/usr/bin' variables. However, now getting an error 'No such file or directory'. – Douglas McDonald May 7 '18 at 23:45
  • @steeldriver I should clarify. With quotes using bash I get error 'No such file or directory'. Without quotes no error — but can't confirm that the renew is working. Might be rate limited? idk. I'll do more testing. In the meantime, if you want to write an answer I'll mark it as correct. – Douglas McDonald May 8 '18 at 0:06
1

Try to specify the entire path to the binaries that you're using. I guess they aren't found since the $HOME variable or $PATH should be different to the root and user.

If what I said is the problem, the source of it must be the location of letsencrypt binary, probably not found by root

  • Good suggestion. I tried it. Works from command line, but unfortunately, still getting the 'not found' error from cron. Here is the revised command/error: /bin/sh: 1: sudo /usr/sbin/service nginx-sp stop && yes | /usr/bin/letsencrypt --standalone renew &>/dev/null && /usr/sbin/service nginx-sp start && /usr/sbin/service nginx-sp reload: not found – Douglas McDonald May 7 '18 at 20:40
  • run this command twice once as user and once as root: whereis service nginx-sp letsencrypt – WiKrIe May 7 '18 at 20:51
  • I'm running everything as root to (hopefully) avoid any user errors. Here is the output: letsencrypt: /usr/bin/lets encrypt /etc/letsencrypt /usr/share/man/man1/letsencrypt.1.gz – Douglas McDonald May 7 '18 at 20:57
  • Did you try the /etc/letsencrypt instead of the /usr/bin/letsencrypt on the crontab? – Manel Reis May 7 '18 at 21:20
  • @ManelReis My understanding is that /etc/letsencrypt is source and not binary. But I tried it regardless. Works from command line, not from cron. I also added full path to yes (/usr/bin/yes) just in case – no luck. – Douglas McDonald May 7 '18 at 21:39
1

This is already reported as issue to script provider:

https://github.com/rehmatworks/serverpilot-letsencrypt/issues/8

So you should wait for an answer there. It is not easy to give you a quality answer if we do not know the total background of the system, looks like some special environment.

Update: Issue is solved now by Scriptowner on Github, please checkout the Github. rehmatworks commented 12 hours ago

Solution: Please reclone the script and you will be able to do much more with great ease.

sorry
chris

  • Thanks Christian. Yes. I'm aware of that. I was one of the posters of the issue. Unfortunately not getting any reply from the dev (been a couple weeks now), and I suspect that it is a general cron issue rather than a script issue. – Douglas McDonald May 7 '18 at 20:44
0

Update: rehmatworks has since updated the original script to address this issue.

Thanks to @steeldriver comments above, I've learned that the main problem is:

  • The crontab should be run using 'bash' (not the default 'sh'), because:
    • &>/dev/null is bash syntax ('sh' would be >/dev/null 2>&1).
    • sh does not recognize commands in quotation marks (produces 'not found' error).
  • The crontab should define the default PATH variables.
  • If the crontab is run under root, then don't need to use 'sudo' (although probably doesn't hurt).

To edit the root crontask, use sudo crontab -e -u root. Final looks like this:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin

@monthly service nginx-sp stop && yes | letsencrypt --standalone renew &>/dev/null && service nginx-sp start && service nginx-sp reload
#

So far, seems like it works (but please confirm by reviewing logs).

Note: Not tested, but in terms of fixing the original install script, without having to define the shell environment separately, it's possible you could wrap the cron command in a bash subshell to make sure it gets run in bash (per askubuntu SE answer):

bash -c "bashcommand"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.