Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Do you see anything in /var/log/cron? What about mail for the user running it from cron? Are you using root to run it?
Removing leading "/" from the tar archive converts the archive from an "absolute" archive that you can only restore to the place it came from, to a "relative" archive which means you can restore the archive to somewhere other than where it was extracted from.
May 12 00:30:00 localhost CROND[19424]: (root) CMD (/var/spool/qmailscan/qmail-queue-log-rotate.sh 2> /dev/null)
And, LogWatch emails me a report that says this as well.
But, the files don't get rotated. Works fine when I run it from the command line (as root).
Do I need to take care of some permissions issue? The script is owned by root.
Also, I changed the paths from full to relative, and the other message I asked about went away. This is now the output when executing it from the command line:
Well, a few things occur to me, which may not directly solve your problem, but are worth considering.
1. Always use the full path to any cmd eg mv, tar, etc in cron, as its default PATH is minimal to put it mildly.
2. tar is for collecting a bunch of files into one (tar cvf) and optionally gzipping (z) or bzip2 (j) to save space.
In your case, only one file is affected, so just use gzip/bzip2, forget tar.
3. trap both the stdout AND stderr:
/var/spool/qmailscan/qmail-queue-log-rotate.sh > /var/spool/qmailscan/qmail-queue-log-rotate.log 2>&1
1. "set -xv" tells bash to output each command as it processes it - a bit like "@echo on" in DOS land.
2. The altered redirection commands say:-
2.1 Output all standard output to your error.txt file.
2.2 The "2>&1" means for standard error, send it to the same place standard output is going. So all output, not just error output, will now go to your error.txt file.
The content of error.txt should now show us each command the script executes (courtesy of the set -xv setting) and all of the errors generated by those commands.
The content of error.txt should now show us each command the script executes (courtesy of the set -xv setting) and all of the errors generated by those commands.
tar -cvzf /var/spool/qmailscan/qmail-queue-backup.tar.gz $LOGFILE
+ tar -cvzf /var/spool/qmailscan/qmail-queue-backup.tar.gz /var/spool/qmailscan/qmail-queue.log
tar: Removing leading `/' from member names
var/spool/qmailscan/qmail-queue.log
echo "" > $LOGFILE
+ echo ''
Yes! The whole thing was the path to the commands. Instead of mv and tar, I changed it to /bin/mv and /bin/tar. That was IT!
(I learned a few other tricks in the process of discovering the obvious flaw...)
But I'm still left wondering why I could run the script from the command line, but from cron there was the path issue. This is a pretty vanilla install of RHEL 4, but the distro shouldn't make much difference, should it?
As mentioned, when you login to a normal cli session, a lot of variables inc PATH are setup (see /etc/profile, ~/.bashrc, ~/.bash_profile) for you.
This does NOT occur in the cron env. The default env vars, inc PATH, are minimal if they even exist.
That's why most (newbie) probs resolve to supplying complete absolute paths to cmds.
It is possible to put some env vars into the crontab, but generally its advisable not to surprise people like that.
Exactly, reduces the risk of running someone else's 'version' of a cmd, which could do anything at all, if they can sneak it into your default PATH.
This is also why your current dir '.' is NOT in your PATH.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.