New answers tagged

1

So the one thing to know about cron is its like env-less. So it might not know about /root/.my.cnf You might want to try the following flag to point to the full path to the config that stores the user/pass --defaults-file=/root/.my.cnf


0

Seems like the issue had been linked to the line prerequisite_check in the script which was placed before all variables had been setup. I moved the check down to below the point where the cron primer is linked and everything worked fine. It is strange that a script so commonly used has such an error without anyone reporting it. I assume the bug had been ...


2

Debian Linux and its derivative (Ubuntu, Mint, etc) have some peculiarities that may prevent your cron jobs from executing; in particular, the files in /etc/cron.d, /etc/cron.{hourly,daily,weekly,monthly} must : be owned by root only be writable by root not be writable by group or other users have a name without any dots '.' or any other special character ...


2

Assuming you're using a setup similar to Openswan's ec2 example , try setting lifetime=1800 rekey=yes but only on the initiating end. This will set SA expiry and renegotiate to every 30 minutes.


0

Function prerequisite_check definition says, basename, cut, date and aws commands should be available. Script is unable to find aws command when running from crontab. Hence, you are hitting error. In crontab, you need to modify PATH variable to include path to aws executable, by writing them before your cron lines. You can use below syntax to add path ...


1

Depending on the cron version/type you are using, the output from the command usually gets sent via email to someone. In the traditional style you can put MAILTO=your.login or maybe even MAILTO=your_email@example.com and get the output from the script. In the worst case try 0 */3 * * * /usr/bin/php /var/acme/cron/api_update_db.php > ...


4

You may be getting some stderr\stdout output which might help identify the problem. Usually this ends up being mailed to yourself, but if not try adding specific redirection of all output to the end of your crontab entry to a file, e.g.: 0 */3 * * * /usr/bin/php /var/acme/cron/api_update_db.php &> /tmp/cron.output


3

crontab -u <username> -e The short answer, run the cron as a user with the appropriate credentials to the database. Source


0

The /etc/cron.daily et. al. scripts are run by a script called run-parts. That script varies. For example the --test switch mentioned above isn't on the machine I'm using at this instant. Run-parts is a bash script. It a generally useful tool for running all the scripts in the directory it's given as an argument. It usually found at /usr/bin/run-parts. ...


2

You need to set the PATH at the beginning of the script or use the full path to protractor. cron uses a default PATH while yours is likely modified by some rc file.


2

you may test the specific file for errors by running in debug mode ; /usr/sbin/logrotate -d /etc/logrotate.d/nginx You may force logrotate to run via specific file as well /usr/sbin/logrotate -f /etc/logrotate.d/nginx In most of the cases -- lograte may fail due to write errors in the specified directory (may be the rotated file is already present ? ...


2

Invoking logrotate manually with the -v option might shed more light on what's going on, be warned that this might be a disruptive operation depending on what logs are rotated. Apart from that, it's hard to say if there's nothing at all in the logs: Checking disk space/free inodes with df could help, inspecting dmesg might give an indication if the disk is ...


0

To troubleshoot Cron it may be handy to run syslog in Docker container. As described here Cron may refuse to interpret its hard-linked configuration files which is a typical situation on Docker's layered overlay(fs) file system. If Cron logs something like NUMBER OF HARD LINKS > 1 (/etc/crontab) to syslog it may help to use the following command in ...


4

(CRON) EXEC FAILED (/usr/sbin/sendmail): Resource temporarily unavailable this isn't a cron problem. from exec(3): The execl(), execle(), execlp(), execvp() and execvP() functions may fail and set errno for any of the errors specified for the library functions execve(2) and malloc(3). from execve(2): [ENOMEM] The new process ...


1

crontab should tell you which line the error is on, so focus on that. I suspect you have a line that's been split in two and "in reality" doesn't have a valid number at the start of the line.


0

I solved this error by adding user munin to group nobody (the same as apache's group) and setting the munin directory writable by the group nobody: chmod -R g+w /usr/local/apache/htdocs/munin Error stopped. Graphs started appearing again.


0

Are you using this php script whit apache ? In this case you should check if apache has the rights to exec those crontabs. Maybe $CMD is not being well parsed, php and bash use the same syntax for the variables... Who is interpreting this? Also I would recommend you to use the exec function instead, so you can debug a little more with the output and ...


0

I had the same issue. Here is a quick fix : for dir in "0 1 2 3 4 5 6 7 8 9 0 A B C D E F" ; do mkdir /var/log/pve/tasks/$dir ; chmod 755 /var/log/pve/tasks/$dir ; done This will create the subdirectories in the /var/log/pve/tasks directory and set the correct permissions.


2

Google says cron would be best for this, but I don't want it to be recurring. Forget about PRTG for anything but monitoring and notifications. It's true - cron jobs are recurring. However, all you need to do is write a simple wrapper script that gets run by cron at the top of each hour - this script would: Check if your program is running. If it is, ...


1

You can do this: 5/10 * * * * caesor sudo python /home/ceasor/Desktop/script.py


6

you'll need three crontab entries: 30-55/5 9 * * * /usr/bin/script-to-run.sh */5 10-15 * * * /usr/bin/script-to-run.sh 0-30/5 16 * * * /usr/bin/script-to-run.sh please do not blame linux, or bsd, or me, for the bizarre and useless syntax of crontab entries. this was invented at AT&T Bell Labs, and later standardized as part of POSIX.


0

Is there a reason you can't do something like: # m h dom mon dow user command */20 * * * * root (/usr/bin/pgrep myscript || /usr/bin/myscript) If the process cannot be found in the current process snapshot table, it returns 1 and executes /usr/bin/myscript. If the process can be found in the current process snapshot table, it returns 0 and stops ...


2

The lock file you specify as the option to /usr/bin/flock; /var/cron.lock remains locked with the flock(2) system call for the duration of your script /usr/bin/myscript. Once your script completes that lock is again released by /usr/bin/flock. When the /usr/bin/flock command can't achieve a lock, , i.e. because /var/cron.lock is already locked because your ...


0

I had exactly the same scenario as described in the question, however the current answer didn't fix the problem for me. In my case, the explanation of the problem was that every time when cron executed sendmail command it was setting $HOME to /, rather than /home/<user>. Thus even if msmtp replaced sendmail via a symlink it was not able to find its ...



Top 50 recent answers are included