New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's Encrypt cron auto-renew doesn't work #836

Closed
gabrielcossette opened this Issue Feb 16, 2017 · 4 comments

Comments

Projects
None yet
5 participants
@gabrielcossette

gabrielcossette commented Feb 16, 2017

Hi,

My Let's Encrypt cron auto-renew doesn't work by default. The command gets executed according to syslog.log but nothing in ee.log.

As suggested in many posts from the forum, I needed to add sudo in front of the crontab command to make it work:

0 0 * * * sudo ee site update --le=renew --all 2> /dev/null # Renew all letsencrypt SSL cert. Set by EasyEngine

If I run the command manually under root without sudo, it works.

Should sudo be added as standard in the crontab entry or is there a better fix?

Thanks!

  • lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial
  • ee -v
EasyEngine v3.7.4
Copyright (c) 2016 rtCamp Solutions Pvt. Ltd.
  • ee info
NGINX (1.10.0):

user                             www-data
worker_processes                 auto
worker_connections               4096
keepalive_timeout                30
fastcgi_read_timeout             300
client_max_body_size             100m
allow                            127.0.0.1 

PHP (5.6.30-1):

user                             
expose_php                       Off
memory_limit                     128M
post_max_size                    100M
upload_max_filesize              100M
max_execution_time               300

Information about www.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   off
listen                           127.0.0.1:9000

Information about debug.conf
ping.path                        /ping
pm.status_path                   /status
process_manager                  ondemand
pm.max_requests                  500
pm.max_children                  100
pm.start_servers                 20
pm.min_spare_servers             10
pm.max_spare_servers             30
request_terminate_timeout        300
xdebug.profiler_enable_trigger   on
listen                           127.0.0.1:9001

MySQL (10.1.21-MariaDB) on localhost:

port                             3306
wait_timeout                     600
interactive_timeout              28800
max_used_connections             11
datadir                          /var/lib/mysql/
socket                           /var/run/mysqld/mysqld.sock
my.cnf [PATH]                    /etc/mysql/conf.d/my.cnf
  • wp --allow-root --info
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/intl.so' - /usr/lib/php/20151012/intl.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/snmp.so' - /usr/lib/php/20151012/snmp.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP binary:     /usr/bin/php7.0
PHP version:    7.0.15-1+deb.sury.org~xenial+1
php.ini used:   /etc/php/7.0/cli/php.ini
WP-CLI root dir:        phar://wp-cli.phar
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 0.24.1
@manojchandrashekar

This comment has been minimized.

Show comment
Hide comment
@manojchandrashekar

manojchandrashekar Feb 28, 2017

Perhaps you need to restart the cron service. Not sure if ee does this.

sudo service cron restart

manojchandrashekar commented Feb 28, 2017

Perhaps you need to restart the cron service. Not sure if ee does this.

sudo service cron restart

@s-a-s-k-i-a

This comment has been minimized.

Show comment
Hide comment
@s-a-s-k-i-a

s-a-s-k-i-a Mar 13, 2017

ee doesnt do this. cron service needs to be restarted manually.

Also make sure it reads the following when running crontab -e in shell:
0 0 * * * sudo ee site update --le=renew --all 2> /dev/null
note sudo here. needs to be added manually as well.
Save. then run service cron restart
you are good to go

@rahul286 Fix or hint in shell after execution of ee site create/update domain.com --letsencrypt/--le=renew could help. Also pls add correct cron job (missing sudo).

s-a-s-k-i-a commented Mar 13, 2017

ee doesnt do this. cron service needs to be restarted manually.

Also make sure it reads the following when running crontab -e in shell:
0 0 * * * sudo ee site update --le=renew --all 2> /dev/null
note sudo here. needs to be added manually as well.
Save. then run service cron restart
you are good to go

@rahul286 Fix or hint in shell after execution of ee site create/update domain.com --letsencrypt/--le=renew could help. Also pls add correct cron job (missing sudo).

@mwaterhouse

This comment has been minimized.

Show comment
Hide comment
@mwaterhouse

mwaterhouse Jul 11, 2017

This all sounds wrong to me. You can't run a cron job using sudo without also providing the sudo password... right? Otherwise a user without sudo permissions could execute anything at sudo level just by putting them in cron.

If the job needs enhanced permissions to run, then it should be in the root crontab, i.e.
sudo crontab -e
Jobs in there will run at root level so you don't need a sudo command ('crontab -e' without the 'sudo' will access your user crontab - different thing)

But the current version of ee is creating the job in the correct crontab anyway. It's also scheduling as '0 0 * * 0' - which is midnight every Sunday (i.e. weekly).

It's also not necessary to restart the cron service - it will pick up any changed crontab files automatically.

mwaterhouse commented Jul 11, 2017

This all sounds wrong to me. You can't run a cron job using sudo without also providing the sudo password... right? Otherwise a user without sudo permissions could execute anything at sudo level just by putting them in cron.

If the job needs enhanced permissions to run, then it should be in the root crontab, i.e.
sudo crontab -e
Jobs in there will run at root level so you don't need a sudo command ('crontab -e' without the 'sudo' will access your user crontab - different thing)

But the current version of ee is creating the job in the correct crontab anyway. It's also scheduling as '0 0 * * 0' - which is midnight every Sunday (i.e. weekly).

It's also not necessary to restart the cron service - it will pick up any changed crontab files automatically.

@rahul286

This comment has been minimized.

Show comment
Hide comment
@rahul286

rahul286 May 29, 2018

Member

We have handled this in a better way in v4.

You may check this PR #1005

Please use http://community.rtcamp.com/c/easyengine for future support questions.

Member

rahul286 commented May 29, 2018

We have handled this in a better way in v4.

You may check this PR #1005

Please use http://community.rtcamp.com/c/easyengine for future support questions.

@rahul286 rahul286 closed this May 29, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment