Manual certificate renewal succeed but auto renewal fail


My operating system is (include version): Ubuntu 14.04.4 LTS

My hosting provider, if applicable, is: AWS

I can login to a root shell on my machine (yes or no, or I don’t know): yes


I used webroot method to create a cert and created a cron script for auto renewal. The thing is when I manually run the cron script, it works perfectly. But when running by cron, it always fails.

Here is my cron script:

Note: This is auto-generated file.

@daily root /home/someuser/letsencrypt/ domain-name1

The script basically does some checking of the existing cert’s expiry date and if less than 30 days, it will start the renewal process. The renewal part looks like this:

log_fn "Certificate expires in ${DAYS_EXP} days."
log_fn “Start renewal process…”

if ! ${CURRDIR}/letsencrypt-auto renew >> ${LOGFILE} 2>&1 ; then
log_fn "Automated renewal process failed. Exiting…"

My log file shows that the cronjob always yields a failure in renewal process:

Wed Sep 28 00:00:01 UTC 2016 Certificate expires in 18 days.

Wed Sep 28 00:00:01 UTC 2016 Start renewal process…

Bootstrapping dependencies for Debian-based OSes…
Ign http:// trusty InRelease
Get:1 http:// trusty-updates InRelease [65.9 kB]
Hit http:// trusty Release.gpg
Hit http:// trusty Release
Get:2 http:// trusty-updates/main Sources [383 kB]
Get:3 http:// trusty-updates/universe Sources [165 kB]
Get:4 http:// trusty-updates/main amd64 Packages [900 kB]
Get:5 http:// trusty-updates/universe amd64 Packages [375 kB]
Get:6 http:// trusty-security InRelease [65.9 kB]
Get:7 http:// trusty-updates/main Translation-en [436 kB]
Get:8 http:// trusty-updates/universe Translation-en [198 kB]
Hit http:// trusty/main Sources
Hit http:// trusty/universe Sources
Hit http:// trusty/main amd64 Packages
Hit http:// trusty/universe amd64 Packages
Hit http:// trusty/main Translation-en
Hit http:// trusty/universe Translation-en
Ign http:// trusty/main Translation-en_US
Ign http:// trusty/universe Translation-en_US
Get:9 http:// trusty-security/main Sources [120 kB]
Get:10 http:// trusty-security/universe Sources [42.5 kB]
Get:11 http:// trusty-security/main amd64 Packages [531 kB]
Get:12 http:// trusty-security/universe amd64 Packages [137 kB]
Get:13 http:// trusty-security/main Translation-en [293 kB]
Get:14 http:// trusty-security/universe Translation-en [82.1 kB]
Fetched 3,794 kB in 6s (582 kB/s)
Reading package lists…
Reading package lists…
Building dependency tree…
Reading state information…
dialog is already the newest version.
gcc is already the newest version.
python is already the newest version.
python-dev is already the newest version.
ca-certificates is already the newest version.
libffi-dev is already the newest version.
python-virtualenv is already the newest version.
The following extra packages will be installed:
Suggested packages:
augeas-doc augeas-tools
Recommended packages:
The following packages will be upgraded:
augeas-lenses libaugeas0 libssl-dev libssl1.0.0
> debconf: unable to initialize frontend: Dialog
> debconf: (TERM is not set, so the dialog frontend is not usable.)
> debconf: falling back to frontend: Readline
> debconf: unable to initialize frontend: Readline
> debconf: (This frontend requires a controlling tty.)
> debconf: falling back to frontend: Teletype
> dpkg-preconfigure: unable to re-open stdin:
4 upgraded, 0 newly installed, 0 to remove and 111 not upgraded.
Need to get 0 B/2,268 kB of archives.
After this operation, 7,168 B of additional disk space will be used.
> dpkg: warning: ‘ldconfig’ not found in PATH or not executable
> dpkg: warning: ‘start-stop-daemon’ not found in PATH or not executable
> dpkg: error: 2 expected programs not found in PATH or not executable
> Note: root’s PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin
E: Sub-process /usr/bin/dpkg returned an error code (2)
Wed Sep 28 00:00:13 UTC 2016 Automated renewal process failed. Exiting…

But when I manually run the command in /etc/cron

sudo /home/someuser/letsencrypt/ domain-name1

The output is successful:

Wed Sep 28 03:20:00 UTC 2016 Certificate expires in 17 days.

Wed Sep 28 03:20:00 UTC 2016 Start renewal process…

Upgrading certbot-auto 0.7.0 to 0.8.1…
Replacing certbot-auto…
Creating virtual environment…
Installing Python packages…
Installation succeeded.

Processing /etc/letsencrypt/renewal/domainname1.conf

new certificate deployed without reload, fullchain is

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/domainname1/fullchain.pem (success)
Wed Sep 28 03:21:30 UTC 2016


The root path have some problem.
I recommend you to use Certbot


My root’s path is

root@ip-xx-xx-xx-xx:/etc/cron.d# echo $PATH

which is identical to my user’s PATH. It is possible that cron is using a different PATH?

Also I am confused why the cron job triggers something looks like a apt-get install output to me, while manually run the script there is nothing like that?


After some testing, I found that:
Cron is having root permission but not using root’s PATH env. I am not sure if this is the case for all linux system. But it definitely is for my AWSes.

Solution of the issue is to add the necessary PATH in my auto renewal script and everything went fine:

export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.