New answers tagged

4

You can just use the editor of your choice to modify the cron.d files. There's no need to use the crontab command.


0

I'd use a wrapper for the script. i.e.: #!/bin/bash RUNAS=user1 if [ "${USER}" == "root" ] then # use sudo to change user sudo -u $RUNAS -H /usr/local/bin/php /path/to/script.php else # run as the current user /usr/local/bin/php /path/to/script.php fi otherwise you could just add sudo to the cron-task: 15 15 * * * root sudo -u user1 -H ...


0

use something like this if you want to avoid the script from being run as root: 15 15 * * * anotheruser /usr/local/bin/php /path/to/script.php In your version the script IS INDEED run as root. The cron line does explicitly say so. I guess your systems administrator and you had a misunderstanding and he meant this: if php-fpm or apache-mod-php ...


0

I had this exact error. Assuming that you have the prerequisites installed and that running the command manually works, but not in Cron, it may be that the correct path is not exposed to the cron command. You can fix this by running crontab -e and then entering the path directly into the cron tab: # Export the path so that the scripts run correctly PATH=/...


4

Monthly is not frequent enough. This script should run at least weekly, and preferably daily. Remember that certs don't get renewed unless they are near to expiration, and monthly would cause your existing certs to occasionally be expired already before they get renewed. The name of the program is certbot, which was renamed from letsencrypt. If you are ...


0

You should use a proper nginx logrotate script on this matter. Here is an example: "/var/log/nginx/*.log" { daily rotate 7 size 100M dateext dateformat -%Y%m%d-%s compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts prerotate ...


0

Try to call tar with the full path. On my system e.g. it's /bin/tar. You can find out with which tar.


0

I'm not familiar with duplicity, but your description about difference between running the script in terminal and by cron would suggest that tasks run by cron could be using a different interpreter. Try adding the following line to the very start of your script file. #!/bin/sh


0

%(percent) means a new line in cron! So you either have to escape it like this foo=a\%2Bb or put your command in a bash file and run that file in crontab.


0

A common reason for things that don't work in cron, but do work in a shell session is a difference of environment. Compare the output of the env when run from cron versus the shell. Recall that a shell launched from cron is non-interactive, which could result in differences in how your init scripts provision your environment.


0

On Debian you can set the macro MAIN_KEEP_ENVIRONMENT = in /etc/exim4/conf.d/main/01_exim4-config_listmacrosdefs or where ever you set your macros. See: /usr/share/doc/exim4/changelog.Debian.gz


0

It works for me */5 * * * * screen -dmS ftp-getter /bin/bash /home/user/ftp-getter.sh >> /var/log/ftp-getter.log 2>&1


0

I got the idea from the answer provided by @segaps To disable: crontab -l | awk '{print "# "$1}' | crontab To enable: crontab -l | cut -c 3- | crontab The only problem with the solution provided by segaps, is that it will uncomment the jobs, that are already commented by the user.


0

You can periodically run crontab -l > my_crontab.backup to backup the crontab into file.


0

I would verify that your cron is actually running. You can look in /var/log/cron and see if there is an entry for that. If not, then possibly verify that the file is executable. If selinux is enabled, you might check in the audit logs.


0

Probably aide output to stderr but not to stdout. Try redirect stderr /sbin/aide --check 2> /tmp/$AIDEOUT Or both stdout and stderr /sbin/aide --check 2>&1 /tmp/$AIDEOUT http://stackoverflow.com/a/637834/205355



Top 50 recent answers are included