So, I have a very simple cron set up to run daily. It does a find and rsync with certain parameters. When it runs on the bash command line, it runs just fine, but when in the root crontab, it doesn't want to know. Any ideas what is wrong here?
/usr/bin/find /var/www/*/logs/ -iname '*.lzma' -mtime +21 -exec rsync -a --ignore-existing --relative -e 'ssh -q -p 2230 -o "StrictHostKeyChecking no"' {} root#nas0:/space/Logs/reporting0/ \;
Syslog shows it ran:
Apr 28 09:40:01 reporting1 CRON[26347]: (root) CMD (/usr/bin/find /var/www/*/logs/ -iname '*.lzma' -mtime +21 -exec rsync -a --ignore-existing --relative -e 'ssh -q -p 2230 -o "StrictHostKeyChecking no"' {} root#nas0:/space/Logs/reporting1/ \;)
But nothing actually gets copied.
Cron always runs with a mostly empty environment. HOME, LOGNAME, and
SHELL are set; and a very limited PATH.
link here
So you can complete all application with the full path or add the environment variables.
For example in Ubuntu you can
replace rsync by /usr/bin/rsync
repalce ssh by /usr/bin/ssh
You can check your cron's environment variable by
add this to cron and check the /tmp/env.output
* * * * * env > /tmp/env.output
here is detail
Related
I'm trying to run the following command on crontab but for some reason it cuts of a portion of the command. when I check /var/logs/cron. However, it runs when I run it on the terminal.
Command in crontab:
*/30 * * * * user find /home/user/recordings -name '*.pcap,SDPerr' -exec sh -c 'mv "$0" "${0%.pcap,SDPerr}.pcap"' {} \;
from /var/logs/cron:
Jan 10 11:00:01 server CROND[116349]: (user) CMD ( find /home/user/recordings -name '*.pcap,SDPerr' -exec sh -c 'mv "$0" "${0)
What am I missing here, any help would be appreciated.
Your command has a % (percent sign) in it, which has special meaning in crontab. Therefore better to put "\" before "%" to escape it.
The following crontab line (on CentOS 7.6)
#daily rsync -rav --remove-source-files --files-from=<(find /home/qa/buildbot/master/packages/rhel7 -type f -mtime +30 -exec basename {} \;) /home/qa/buildbot/master/packages/rhel7 192.168.1.31:/local/raid0/buildbotpackages/packages/rhel7
fails, and sends me the following email message:
From: (Cron Daemon) <crontab#docker.local>
Subject: Cron <qa#docker> rsync -rav --remove-source-files --files-from=<(find /home/qa/buildbot/master/packages/rhel7 -type f -mtime +30 -exec basename {} \;) /home/qa/buildbot/master/packages/rhel7 192.168.1.31:/local/raid0/buildbotpackages/packages/rhel7
rsync: failed to open files-from file <(find /home/qa/buildbot/master/packages/rhel7 -type f -mtime +30 -exec basename {} ;): No such file or directory
rsync error: syntax or usage error (code 1) at main.c(1567) [client=3.1.2]
I looked at the source code of rsync's main.c, but could not see the relevance of line 1567:
1557 SIGACTMASK(SIGINT, sig_int);
1558 SIGACTMASK(SIGHUP, sig_int);
1559 SIGACTMASK(SIGTERM, sig_int);
1560 #if defined HAVE_SIGACTION && HAVE_SIGPROCMASK
1561 sigprocmask(SIG_UNBLOCK, &sigmask, NULL);
1562 #endif
1563
1564 /* Ignore SIGPIPE; we consistently check error codes and will
1565 * see the EPIPE. */
1566 SIGACTION(SIGPIPE, SIG_IGN);
1567 #ifdef SIGXFSZ
1568 SIGACTION(SIGXFSZ, SIG_IGN);
1569 #endif
1570
1571 /* Initialize change_dir() here because on some old systems getcwd
1572 * (implemented by forking "pwd" and reading its output) doesn't
1573 * work when there are other child processes. Also, on all systems
1574 * that implement getcwd that way "pwd" can't be found after chroot. */
1575 change_dir(NULL, CD_NORMAL);
1576
1577 init_flist();
Furthermore, when I run that exact crontab line from the shell, it works:
qa#docker /tmp$ rsync -rav --remove-source-files --files-from=<(find /home/qa/buildbot/master/packages/rhel7 -type f -mtime +30 -exec basename {} \;) /home/qa/buildbot/master/packages/rhel7 192.168.1.31:/local/raid0/buildbotpackages/packages/rhel7
sending incremental file list
sent 18 bytes received 12 bytes 20.00 bytes/sec
total size is 0 speedup is 0.00
qa#docker /tmp$
Any ideas on how to debug this issue?
Broken cron jobs are frequently caused by testing the command in a different shell from the one cron uses. Most of the popular interactive shells like bash and zsh and the standard /bin/sh (used by cron) have similar basic syntax, because they're all descended from the Bourne shell. The similarity between them is strong enough that you can get by, for a while, thinking that cron's command syntax is the same as your login shell.
When you put more complex commands into a crontab, you find that there are differences. In your example, I suspect the command substitution operator <(...). This type of substitution didn't exist in Bourne shell, and I don't think POSIX has adopted it either, so I wouldn't trust it in a cron job.
Test your command in /bin/sh on your system by simply running one within your other shell:
BIG-FANCY-PROMPT%>$ sh
$ rsync -rav --remove-source-files --files-from=<(find /home/qa/buildbot/master/packages/rhel7 -type f -mtime +30 -exec basename {} \;) /home/qa/buildbot/master/packages/rhel7 192.168.1.31:/local/raid0/buildbotpackages/packages/rhel7
... probably some error message here...
$ exit
BIG-FANCY-PROMPT%>$ _
If you can't think of a way to rewrite the command in sh syntax, you can always explicitly invoke bash or any other shell you like:
#daily bash -c '...'
This way involves an extra layer of quoting so that sh will pass the whole command to bash without trying to parse it. If that becomes too difficult, then put your command in a script with a nice #! line and run that from cron.
I have a crontab job to purge the logs from /var/log/nginx folder. The crontab was set up like this:
15 23 * * * /scripts/logcleanup.sh > /dev/null 2>&1
The logcleanup.sh script is very simple, it only has two line:
find /var/log/nginx -mtime +5 -type f -delete;
find /var/log/nginx -size +50M -type f -delete;
I supposed the script will be run every night at 23:15. However, it doesn't get executed and the files larger than 50 MB are still inside the log folder. Is this caused by the missing Shebang "#!/usr/bin/env bash" ?
Thanks.
Redirect the output to a log file instead of /dev/null to get feedback:
15 23 * * * /scripts/logcleanup.sh > ~/logcleanup.sh.log 2>&1
All the errors will be logged and hopefully, you will find out what is wrong.
I have the following script that works fine when called from the command line:
#!/bin/sh
/usr/bin/mysqldump -u root -ppassword redmine > /home/administrateur/backup/backup_$(date+%Y-%m-%d-%H.%M.%S).sql
find /home/administrateur/backup/* -mtime +15 -exec rm {} \;
rsync -e 'ssh -p 22' -avzp /home/administrateur/backup is-uber-1:/home/administrateur/backup
But this script omits the rsync line when called from cron.
Does anyone know why?
Basically you need to run your script as administrateur. You can use sudo for it:
/usr/bin/sudo -H -u administrateur -- /bin/sh /path/to/your/script.sh
I found this bash script online that I want to use to delete files older than 2 days:
#!/bin/bash
find /path/to/dir -type f -mtime +2 -exec rm {} \;
I setup a cronjob to run the script (I set it a couple of minutes ahead for testing, but it should run once every 24 hours)
54 18 * * * /path/to/another/dir/script.sh
I exit correct so it updates the cronjob.
Why does it not delete the files in the directory?
What if you try dumping an echo at the end of the script and log the output
cron1.sh >> /var/log/cron1.log
You could try this but I'm not sure it will work
--exec rm -rf {}
Most cron jobs do not have PATH set. You must fully qualify the find command.
#!/bin/bash
/usr/bin/find /path/to/dir -type f -mtime +2 -exec rm {} \;
If you capture the stdout and stderr as recommended by damienfrancois, you'd probably see the message "command not found: find". If you didn't capture the stdout and stderr, cron usually will send the output to the cron job owner's email, unless configured not to do so.