Different output to file when running scritp from crontab
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.
Distribution: Red Hat (8.0, RHEL5,6), CentOS, SuSE (10.x, 11.x, 12.2, 13.2), Solaris (8-10), Tru64, MacOS, Raspian
Originally Posted by junda
I am trying to get the uptime from some linux servers and redirecting the information to a file. After a day of going back and forward I was able to create the scritip that would do what I wanted.
The problem I am having is that when I schedule the script to run from cron it will not give me the same output.
Try running a script that does nothing but execute "set | sort" from both the CLI and as a cron job.
Scripts that run as cron job do necessarily have the same shell environment as you see when using the CLI; your profile (.profile, etc.) does not get sourced when you execute something under cron. I suspect the difference in output you're seeing is due to something that different in the two environments. The comparing the two outputs from this test script will allow you to see what's different and recreate whatever's missing in the script that your executing.
* changed the SHELL=/bin/sh to SHELL=/bin/bash in the /etc/crontab file and restarted cron service but didnt work
* added "SHELL=/bin/bash in the first line of the crontab jobs but didnt work
* ran the cron job as follows "* * * * * /bin/bash /usr/local/sbin/statuscheck.sh" didnt work
(1) Output file i.e. $file is already get updated with all info. in you script itself, then you need not to redirect output in same file again while declaring it in crontab, and also no need to use 2>&1.
(2) Crontab entry also doesn't look ok. All * means every minute of every hour of every week day of every month... isn't it? So make sure that at what time you want to run it.
* you are right about the output file i removed that from the cron job
* cron job is running at the times I want and updating the output file. I am not running it every minut of every hour etc.... that was just to ilustrate the cron job
* I do not care about getting a mail at all, all I want is for the script to run in cron the same way it runs in the command line.
I think that for some reason cron is not sending the password, since thats as far as it writes to the file:
this is what I get for each server once I remove the grep filtering from the script:
I'm not sure what's causing this. A couple of things I've always watched out for in expect scripts are: a.) be sure you match the case of the string your expecting -- for example, if you're not sure whether a string is capitalized or not try looking for "assword" and b.) if the string is complicated enough you can include wildcards and use a pattern like "*assword*".
Oddly, it doesn't seem to matter if I use 'expect password', 'expect Password', or 'expect "*assword*"', I get the same output from uptime (when run interactively) even though the actual password prompt is "Password: ". The first one returned the uptime string in about 10 seconds and the second version took 0.5s. The third one matched -- again in 0.5s -- because of the wildcards. I think the 10 second delay is the default timeout value for expect. Now I'm trying to figure out what is going on with the authentication. I would have expected the first spawn to fail during the ssh connection and go ahead and issue the "uptime" command and probably return the uptime of the local host. But it didn't fail; there are entries in the remote side's /var/log/messages corresponding to the ssh connections attempted by the expect command. And the uptime numbers are from the remote host.
Usually, by default, output from a command run from a crontab is E-Mailed, such as with sendmail, to the "owner" of the crontab, unless that's overridden by setting the MAILTO variable.
Are you using local E-Mail facilities at all on your system, such as sendmail to transfer the E-Mail, and something like mailx to read it, with the MAIL shell variable set when you log in as root? You might want to take a look at the system logs to see if there are complaints that E-Mail can't be sent, as well as to see if there might be other related errors.
Also, some programs, which expect a "controlling terminal", may not behave well when there is no such thing available.
Output from crontabs can instead be sent to syslog with the -s option. When you appear to get no output, you might want to try the -s option on cron itself.
Often various system log files can be found in /var/log. Sometimes even if you don't know which one to examine, running a command sequence such as:
ls -lat /var/log/* | less
the moment after the cron command should have run, will show you which logs have recently been written to, as the most recently written to log files, will be near the top of the list.
Unless you are using something specific to bash, whether the Bourne shell or bash is being run, shouldn't necessarily make much difference.
I do not care about getting a mail at all, all I want is for the script to run in cron the same way it runs in the command line.
To be honest, I am not much aware about expect cmd and it's usage. But to get a mail everytime your script runs, you can specify it in your crontab entry or in script itself, as:
If specifying in crontab: