I'm not having SSH access, only cronjob access.
I've written a copy.sh script in order to rsync the folders, but it does not happen. Why?
OLDDIR="/var/www/web46/html/magento-v2"
NEWDIR="/var/www/web46/html/magento-v4"
rsync -au $OLDDIR/media/ $NEWDIR/media >> log.txt
# rsync -au $OLDDIR/app/code/ $NEWDIR/app/code
# rsync -au $OLDDIR/app/design/ $NEWDIR/app/design
# rsync -au $OLDDIR/app/etc/modules/ $NEWDIR/app/etc/modules
# rsync -au $OLDDIR/app/locale/ $NEWDIR/app/locale
# rsync -au $OLDDIR/js/ $NEWDIR/js
# rsync -au $OLDDIR/skin/ $NEWDIR/skin
This is the target folder:
This is the destination folder AFTER the script has run:
What am I doing wrong?
Update
For any shell script running from a cron:
Use full paths. (Both in the script, and in the crontab referencing the script)
Ensure the script is made executable and that the correct user has permissions to run. (see
Regarding Magento:
Make sure you use crontab syntax applicable to magento.
See this example setup from this answer: https://magento.stackexchange.com/a/63717
*/5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=default
*/5 * * * * www-data /bin/sh /path/to/magento/cron.sh cron.php -m=always
Consider posting your question in http://magento.stackexchange.com if these basic steps don't help.
NOTE: Most tutorials / help guides / help forums, will assume, rightly or wrongly, the default position that you are a system admin, given that you are troubleshooting an admin level task. Please specify your exact constraints.
Refer to Check your existing crontab
troubleshooting page
Check your existing crontab
To verify whether or not your crontab is set up:
Log in to your Magento server. As a user with root privileges, see if
a crontab is already set up.
crontab -u <Magento file system owner name> -l
For example, on CentOS
crontab -u magento_user -l
If no crontab has been set up for the user,
the following message displays:
no crontab for magento_user
See one of the following sections for a
solution to your issue.
Solution: crontab not set up
To verify your cron jobs are set up properly, see Set up cron jobs.
This sample script adds full paths and a shebang line to your rsync script. Note: you may need to be able to test this outside of the cron to pinpoint the issue :
#!/bin/bash
echo "At least I know the script ran up to here" > /var/log/myscriptran.log
OLDDIR="/usr/share/full-path/something/magento-v2"
NEWDIR="/usr/share/full-path/something/magento-v4"
/usr/bin/rsync -au "$OLDDIR/media/" "$NEWDIR/media" 2>> /var/log/rsync_cron.log
Additionally: If for some reason you need to run in the same environment, you can always add source /User/your/home/folder/path/.profile (replace with your applicable profile path).
Crontab runs in it's own environment, you need to assume it has no knowledge of you, your home folder, relative paths, your ssh certificates location, any common environment variables / settings that you may not even be aware of, etc.
What it will always understand is full paths, and it will execute, executable files, it has permission to run.
Related
I've accidentally ran 'crontab *'. Afterwards, crontab -l and, possibly, crontab -e stopped working properly.
Can someone more knowledgeable in cron help me explain what would happen if 'crontab *' command is ran?
I ran crontab -l | grep * and very few cronjobs showed up. I also ran crontab -e in order to edit the crontab file and it gives me the "Error detected while procedssing 'pathway'" message and "E518: Unknown option: foldmehod=marker" error. It brings me to /tmp/crontab* where * denotes an attempt to create a cron file at tmp folder.
I expect the output of crontab -l | grep "name" to output something but the output doesn't show anything. I suspect it's me running crontab *.
In short, the result would be crontab attempting to install every file that * would have expanded to. Since you did not specify a user with -u first, it would have defaulted to whatever user you were executing the command as. The good news is this only messed up your private crontab.
Cron uses two different crontabs; a system-wide crontab at /etc/crontab and the private, user-specific crontabs at /var/spool/cron. When you use crontab, for example as root, to install a new file, those changes are actually made to /var/spool/cron/root, not the global crontab found at /etc/crontab.
Thus the damage is mitigated to the private crontab of whichever user ran that command, which you can most likely safely remove and rebuild if necessary; but whatever is inside of that private crontab is going to be junk.
When I want to compress a folder manually I use the command:
tar -zcvf $dirBackup-$actualTime.tgz $dirBackup;
And it works perfectly. Also when I decompress the archive the result is correct.
But I have a problem when I run the same command from crontab: the resulting tgz only appears to contain an empty file.
crontab -l>> /home/user/Desktop/test/temp;
echo "$min $hour * * * tar -zcvf $dirBackup-$actualTime.tgz $dirBackup">> temp;
crontab temp;
Do I need to change anything in the crontab expression? Do I have to be root to run crontab? The file temp is created correctly, and located in the right folder.
Thanks a lot for your attention!
Depending on your system, crontab jobs may or may not be run in your $HOME directory (in fact they are typically run either in / or in /var/cron). Add a cd $HOME; before the tar command.
You need to set the value of the variables in the echo command you are using to add entry into the cron job. A sample script should look like this:
#!/bin/bash
min=30
hour=17
dirBackup=/home/user/Desktop
actualTime=30-04-2015
crontab -l >> /home/user/temp
echo "$min $hour * * * tar -zcvf $dirBackup-$actualTime.tgz $dirBackup 2>&1 | tee /tmp/cron.log">> /home/user/temp;
crontab /home/user/temp;
The resulting tar file will be created in the user's HOME directory (user with which the cron is run).
To avoid getting into user permission issues, you can specify the user with which the cron is to be run using the following command:
crontab -u <username> <cron_file>
Wondered if anyone had any idea why the following problem is occurring, or had any tips where to look…I can run the shell script manually in ssh, but if I set it up to run in crontab i get the problems below.
Server is: FreeBSD 8, and I have access to all root permissions
I have a shell script (Bourne) that runs under the “root” permissions using crontab with the following command:
* * * * * /data/backups/scripts/server_log_check.sh > /data/backups/logs/cron_logs/server_log_check.sh_cron.log
The “server_log_check.sh” script checks to see if “the report server” is running with this command:
if ps -xauww | grep -v grep | grep java | grep www > /dev/null
then
#“reports are running, no need to try to restart it”
Else
/usr/local/etc/rc.d/tomcat55 start #start report server because it is not running
Fi
The problem is occurring on this line: “/usr/local/etc/rc.d/tomcat55 start”, when the script is run using crontab, but if I run the script manually via ssh this line of code runs without a problem, but all the rest of the code in the script executes fine, just not this line. Allternatively, if I paste this line /usr/local/etc/rc.d/tomcat55 start into the ssh command prompt, it runs just fine too.
I changed the “server_log_check.sh” ownership to be “root”, but that didn’t make a difference, and the script "tomcat55" ownership is "www". The crontab entry is being made under the "Root" profile, so, I assumed there is no problem running a file that is owned by a lessor permission such as "www" has
Do you have any ideas why cron is doing this?
Thanks in advance
Try adding the following which will add the error to the log file as well:
* * * * * /data/backups/scripts/server_log_check.sh > /data/backups/logs/cron_logs/server_log_check.sh_cron.log 2>&1
Also change this:
/usr/local/etc/rc.d/tomcat55 start
to:
cd /home/root
nohup /usr/local/etc/rc.d/tomcat55 start &
This should create a nohup.out in /home/root.
This question already has answers here:
CronJob not running
(19 answers)
Closed last month.
I have a cron job that I want to execute every 5 minutes:
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /scr_temp/scheduleSpider.sh
In /var/spool/cron/crontabs/root
The cron should execute a shell script:
#!/bin/sh
if [ ! -f "sync.txt" ]; then
touch "sync.txt"
chmod 777 /scr_temp
curl someLink
fi
That works fine from command line but not from cron. However the cron itself is startet but the script does not start.
I read about the path problem but I dont really understand it. I setup a cron that writes some env data to a file. This is the output:
HOME=/root
LOGNAME=root
PATH=/usr/bin:/bin
SHELL=/bin/sh
If I execute the env command in command line I get following output for PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
What path do I have to set in my shell script?
Your $PATH is fine; leave it alone. On Ubuntu, all the commands you're invoking (touch, chmod, curl) are in /bin and/or /usr/bin.
How did you set up the cron job? Did you run crontab some-file as root?
It seems that /etc/crontab is the usual mechanism for running cron commands as root. On my Ubuntu system, sudo crontab -l says no crontab for root. Running crontab as root, as you would for any non-root account, should be ok, but you might consider using /etc/crontab instead. Note that it uses a different syntax than an ordinary crontab, as explained in the comments at the top of /etc/crontab:
$ head -5 /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
Run sudo crontab -l. Does it show your command?
Temporarily modify your script so it always produces some visible output. For example, add the following right after the #!/bin/sh:
echo "Running scheduleSpider.sh at \`date\`" >> /tmp/scheduleSpider.sh.log
and see what's in /tmp/scheduleSpider.sh.log after a few minutes. (You can set the command to run every minute so you don't have to wait as long for results.) If that works (it should), you can add more echo commands to your script to see in detail what it's doing.
It looks like your script is designed to run only once; it creates the sync.txt file to prevent it from running again. That could be the root (ahem) of your problem. What that your intent? Did you mean to delete sync.txt after running the command, and just forgot to do it?
root's home directory on Ubuntu is /root. The first time your script runs, it should create /root/sync.txt. Does that file exist? If so, how old is it?
Note that curl someLink (assuming someLink is a valid URL) will just dump the content from the specified link to standard output. Was that your intent (it will show up as e-mail to root? Or did you just not show us the entire command?
First: you can substitute the first field with */5 (see man 5 crontab)
Second: have cron mail the output to your email address by entering MAILTO=your#email.address in your crontab. If the script has any output, it'll be mailed. Instead of that, you may have a local mailbox in which you can find the cron output (usually $MAIL).
A better syntax for you CRON is
*/5 * * * * /scr_temp/scheduleSpider.sh
Also, check the authority of your scheduleSpider.sh file. Cron runs under a different user than the one you are likely executing your program interactively, so it may be that cron does not have authority. Try chmod 777 for now, just to check.
I suggest to:
check that /scr_temp/scheduleSpider.sh has executable bit
set PATH properly inside your script or use absolute path to command (/bin/touch instead of touch)
specify absolute path to sync.txt file (or calculate it relatively to script)
Have you added the comand via crontab -e or just by editing the crontab file? You should use crontab -e to get it correctly updated.
Set the working directory in the cron script, it probably doesn't execute the things where you think it should.
You should add /bin/sh before the absolute path of your script.
*/5 * * * * /bin/sh /scr_temp/scheduleSpider.sh
I have a svn backup script in a redhat linux. let's it called svnbackup.sh
It works fine, when I run it in terminal.
But when I put it into crontab, it will not bring the svnserve back, even the data is backuped correctly.
What's wrong with me???
killall svnserve
tar -zcf /svndir /backup/
svnserve -d -r /svndir
Usually, 'environment' is the problem in a cron job that works when run 'at the terminal' but not when it is run by cron. Most probably, your PATH is not set to include the directory where you keep svnserve.
Either use an absolute pathname for svnserve or set PATH appropriately in the script.
You can debug, in part, by adding a line such as:
env > /tmp/cron.job.env
to your script to see exactly how little environment is set when your cron job is run.
If you are trying to backup a live version of a repository, you probably should be using svnadmin hotcopy. That said, here are a few possibilities that come to mind as to what might be wrong:
You've put each of those statements as separate entries in your crontab (can't tell from the Q).
The svnserve command takes a password, which cron, in turn, cannot supply.
The svnserve command blocks or hangs indefinitely and gets killed by cron.
The command svnserve is not in your PATH in cron.
Assuming that svnserve does not take a password, this might fix the problem:
#! /bin/bash
# backup_and_restart_svnserve.sh
export PATH=/bin:/sbin:/usr/bin:/usr/local/bin # set up your path here
killall svnserve && \
tar -zcf /svndir /backup/ && \
svnserve -d -r /svndir >/dev/null 2>&1 &
Now, use "backup_and_restart_svnserve.sh" as the script to execute. Since it runs in the background, it should hopefully continue running even when cron executes the next task.