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!
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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
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.