Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
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.
As you can see, it's a simple bash script execution. As the script has some "echo" commands inside it, I want to log these output on a log file.
I'm connecting to this linux server using Putty. My problem is I realized that meanwhile Putty console is opened and connected a line is generated inside the file "con_switch_diario.log" every 10 minutes (i.e., the script is running).
But when I closed that Putty console (i.e., the ssh connection is finished) and then I reopened it, I found that there aren't entries on that log file during that lapse of time.
So, I don't know if the script is not running during the time that the Putty console is closed, or it's a problem with the log file.
I deleted the crontab and re-created a new one, but the problem persist.
When you do 2>&1 first you're telling the script to send errors to whatever the stdout was BEFORE you defined it as /var/log/con_switch_diario.log. By doing 2>&1 second you're telling it to use the stdout you just defined.
Since we don't know what is in con_switch6.sh we can't really comment on the rest of it.
Note that jobs run in cron have minimal environments as opposed to what they have when you run them from a command line. At command line they inherit variables setup by things like /etc/profile, /etc/bashrc, $HOME/.bashrc, $HOME/.bash_profile etc... but they don't in cron. This means you often have to include the variables that you need in the script itself.
Chief among these is the PATH variable that tells it where to find the commands it is using.
Thank you for your answer, but the problem is not the "2>&1" before the ">> /var/log/con_switch_diario.log".
I changed it and I continue with the same problem. And I have other server linux with a similar script programmed by crontab in the same way that is working fine with the console closed.
I'm aware of the problem with the variables, but inside the script I just using tipical linux-bash commands as "if", "traceroute", "ping", "echo", "mail", etc.
The only odd thing is that from inside this script is called an "expect" script. But in this case I'm using full paths.
And besides it currently the script doesn't have to execute it because it has an "if/else" that run just this command:
traceroute -m 3 www.domain.com | grep $IP2
The output of this command above should be recorded inside the log file, and it isn't (when the ssh console is closed).
I don't see full path on either the traceroute or grep command despite you're having indicated you had all the commands with full paths on them. (You don't actually need full path on the commands themselves so long as your PATH variable includes the directories where the commands live but I'm mentioning it because of what you said.)
Also if you're using things such as if, for, while etc... that are internal commands to the shell you need to make sure your script includes the interpreter line (e.g. #!/bin/bash) so it is definitely using the shell you expect to get those internals.
expect does extra things so may have other things you need to do.
However wanted to note a possible reason why using backticks `` rather than the variable/parentheses $() worked:
Your script has interpreter line as "#/bin/sh". On Linux that is typically linked to another shell usually /bin/bash but on more than one system I've found it linked to /bin/dash or something else and dash does NOT run the same as bash.
When writing scripts rather than relying on links it is best to put in the shell you really want to use so instead of having "#/bin/sh" you should use "#/bin/bash" (or "#/bin/ksh" or "#/bin/dash" or whatever the path is to the shell you really want).