Please post what Operating System and version you are running and what Shell you normally use (regardless of the default Shell for you cron).
If there is something fundamental wrong, the error message will be found in unix mail for the owner of the crontab.
A common issue would be if /home/myfolder/abc.sh was not executable by the owner of the cron.
Ps. The script as posted in post #3 contains many syntax/design? errors and there is no way that it works with or without cron. Please outline what the script is intended to do because deducing this from faulty code is impossible.
Pps. Please post in proper English not textspeak.
Ppps. The script in the crontab line as posted the script takes a parameter. Nowhere in the the posted script is the parameter referenced. Hmm, perhaps the crontab line is wrong.
Perhaps the crontab line should be something like this:
I think that an important question is where precisely in the directory tree for your server is the directory my_ARCHIVE ? Please be aware that the \ character in unix protects a character from interpretation by the Shell whereas a / character could be part of a path describing a directory tree. Microsoft Operating systems use \ characters in path names,but unix Operating Systems use / in path names.
for croning the script and now a blank abc.log file is getting generated at the path home/myfolder and the time stamp of the blank abc.log file also gets updated after every 5 minutes. But seems the shell script is still not getting executed.
-> the script is written to transfer .dmp file from unix server to a windows OS server using ftp. the script first zips the .dmp file and than transfers it.
-> when logging to the unix system through putty and executing the following command manually:
sh abc.sh
the script executes properly and the file gets transferred to the home directory of the apache server installed in the windows system.
-> I have been granted a user account in this unix server. 'myfolder' is the folder by my name located at the path: root/home/myfolder.
-> I have placed the script 'abc.sh' in this 'myfolder' as i have access to only this folder and i can't access any other folder in the system. The .dmp file is also located in the same folder as the script.
The blank abc.log file is generated at the same folder.
-> The 'my_ARCHIVE' folder is created in the folder 'myfolder'. The script after copying the file to the windows system should move the file to this 'my_ARCHIVE' folder.
Question: Is this issue related to access and permissions?
I am the owner of the crontab and the crontab is expected to execute the shell script which is present in the folder where i have read-write access.
Is it that the cron job is not able to access the script? If thats the case, how can it be confirmed and what permissions need to be granted to me for the same?
Thanks.
---------- Post updated at 05:56 PM ---------- Previous update was at 05:40 PM ----------
Hi Corona688,
I entered the profile path as mentioned below but still the cron job not able to execute the shell script.
Please post:
# From the local server (blotting anything confidential with X's).
id
ls -lad /home/myfolder/abc.sh
cat /home/myfolder/abc.sh
root/home/myfolder is not an absolute path. Where is the directory in the filesystem?
Please post what Operating System and version you are running and what Shell this is, blotting anything confidential like computer names and licences with X's.
The script /home/myfolder/abc.sh as posted is rather buggy. All is does is execute a large echo of everything between the two double quote characters and dumps it into a new file called ftp in the current working directory! You may wish to find this output file, check the contents and then delete it.
The script itself needs to positively state directory names and also needs to use ftp -i to stop ftp prompting after every file in a mput .
Folder names came from your narrative. I can't claim to fully understand your folder structure, so do check it.
In you post you say that your Shell is /bin/bash but your shebang line at the top of the script says /bin/sh . On some systems they are actually the same program, but do check.
This suggested code is to demonstrate the correct structure for the script (minus the echo ) and to illustrate the need to have a cd to give filenames some context when running from cron.
Untested.
#!/bin/sh
cd /home/myfolder
HOST='XXX.XXX.XX.XXX'
USER='XXX'
PASSWD='XXX'
FILE='*.gz'
gzip *.dmp
ftp -in $HOST <<END_SCRIPT > ftp_$$.log
quote USER $USER
quote PASS $PASSWD
mput $FILE
quit
END_SCRIPT
cd my_ARCHIVE
rm $FILE
cd ..
mv $FILE my_ARCHIVE
exit 0
Consider commenting out the rm line while testing and do make sure that you have a copy of your *.dmp files so you can test again and again.
Hi Methyl,
I tested the script with contents as mentioned by you but that did'nt work through cron job.
In order to test if the issue is related to wrong scripting ode, I created the following simple script.
#!/bin/bash
cd /home/myfolder
FILE='*.dmp'
rm $FILE
exit 0
This script if executed manually through putty: sh xyz.sh removes the .dmp file from the myfolder.
The same script when cronned: generates a blank log file but does not removes the .dmp file.
I am really not sure whatss going wrong now.
Output for ls -lad /home/myfolder/abc.sh :
-rw-rw-rw- 1 myname myname 296 Jul 4 19:06 /home/myname/abc.sh
The script is not executable. There should have been an error in unix mail for the owner of the cron.
The way you are running scripts from the command line by starting a new shell with a script name as a parameter sh scriptname rather than ./scriptname or /home/myfolder/abc.sh is masking the problem. You were not typing the same command as you gave to cron.
The current permissions are 555 (i.e. not executable by anybody, and that includes cron). You need to make your scripts executable if you want to run them from cron:
Thanks Methyl, The script is now working through cron.
the issue was with the permissions on the script. After providing permissions- chmod 755 the issue got resolved.
@Corona688
Didn't pick up the way the O/P runs scripts until post #14 , though the permissions were in post #12 (my bad). I've just highlighted the command in post #14 because it was in the middle of a sentence.
I concentrated on the fact the the original script didn't execute anything except the echo . It was of course the redirect on the crontab line which would have created the empty log whether or not the script actually ran.
Obviously the O/P doesn't see unix mail because if the original cron has been running for a couple of days there will be quite a few emails (288 per day)!