amazon ec2centoslinuxrsyncssh
when I run the following manually it runs perfectly:
/usr/bin/rsync -arvth -e "ssh -i /watch/scripts/word.pem" 1.1.1.1:/opt/ /opt
when it runs using crontab. I get:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: unexplained error (code 255) at io.c(600) [receiver=3.0.6]
what am I missing here?
Thanks!
Dotan.
This is a community wiki, if you notice anything incorrect with this answer or have additional information then please edit it.
Every user on a system may have their own crontab file. The location of the root and user crontab files are system dependant but they are generally below /var/spool/cron.
There is a system-wide /etc/crontab file, the /etc/cron.d directory may contain crontab fragments which are also read and actioned by cron. Some Linux distributions (eg, Red Hat) also have /etc/cron.{hourly,daily,weekly,monthly} which are directories, scripts inside which will be executed every hour/day/week/month, with root privilege.
root can always use the crontab command; regular users may or may not be granted access. When you edit the crontab file with the command crontab -e and save it, crond checks it for basic validity but does not guarantee your crontab file is correctly formed. There is a file called cron.deny which will specify which users cannot use cron. The cron.deny file location is system dependent and can be deleted which will allow all users to use cron.
If the computer is not powered on or crond daemon is not running, and the date/time for a command to run has passed, crond will not catchup and run past queries.
A crontab command is represented by a single line. You cannot use \ to extend a command over multiple lines. The hash (#) sign represents a comment which means anything on that line is ignored by cron. Leading whitespace and blank lines are ignored.
Be VERY careful when using the percent (%) sign in your command. Unless they are escaped \% they are converted into newlines and everything after the first non-escaped % is passed to your command on stdin.
There are two formats for crontab files:
User crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7)
# | | | | |
# * * * * * command to be executed
System wide /etc/crontab and /etc/cron.d fragments
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7)
# | | | | |
# * * * * * user-name command to be executed
Notice that the latter requires a user-name. The command will be run as the named user.
The first 5 fields of the line represent the time(s) when the command should be run. You can use numbers or where applicable day/month names in the time specification.
,) is used to specify a list e.g 1,4,6,8 which means run at 1,4,6,8.-) and may be combined with lists e.g. 1-3,9-12 which means between 1 and 3 then between 9 and 12./ character can be used to introduce a step e.g. 2/5 which means starting at 2 then every 5 (2,7,12,17,22...). They do not wrap past the end.*) in a field signifies the entire range for that field (e.g. 0-59 for the minute field).*/2 signifies starting at the minimum for the relevant field then every 2 e.g. 0 for minutes( 0,2...58), 1 for months (1,3 ... 11) etc.By default cron will mail any output from the command to the user it is running the command as. If there is no output there will be no mail. If you want cron to send mail to a different account then you can set the MAILTO environment variable in the crontab file e.g.
MAILTO=user@somehost.tld
1 2 * * * /path/to/your/command
You can redirect stdout and stderr to a file. The exact syntax for capturing output may vary depending on what shell cron is using. Here are two examples which save all output to a file at /tmp/mycommand.log:
1 2 * * * /path/to/your/command &>/tmp/mycommand.log
1 2 * * * /path/to/your/command >/tmp/mycommand.log 2>&1
Cron logs its actions via syslog, which (depending on your setup) often go to /var/log/cron or /var/log/syslog.
If required you can filter the cron statements with e.g.
grep CRON /var/log/syslog
Now that we've gone over the basics of cron, where the files are and how to use them let's look at some common problems.
If cron isn't running then your commands won't be scheduled ...
ps -ef | grep cron | grep -v grep
should get you something like
root 1224 1 0 Nov16 ? 00:00:03 cron
or
root 2018 1 0 Nov14 ? 00:00:06 crond
If not restart it
/sbin/service cron start
or
/sbin/service crond start
There may be other methods; use what your distro provides.
What environment variables are available is likely to be very limited. Typically, you'll only get a few variables defined, such as $LOGNAME, $HOME, and $PATH.
Of particular note is the PATH is restricted to /bin:/usr/bin. The vast majority of "my cron script doesn't work" problems are caused by this restrictive path. If your command is in a different location you can solve this in a couple of ways:
Provide the full path to your command.
1 2 * * * /path/to/your/command
Provide a suitable PATH in the crontab file
PATH=/bin:/usr/bin:/path/to/something/else
1 2 * * * command
If your command requires other environment variables you can define them in the crontab file too.
Regardless of where the program you execute resides on the filesystem, the current working directory of the program when cron runs it will be the user's home directory. If you access files in your program, you'll need to take this into account if you use relative paths, or (preferably) just use fully-qualified paths everywhere, and save everyone a whole lot of confusion.
Cron generally requires that commands are terminated with a new line. Edit your crontab; go to the end of the line which contains the last command and insert a new line (press enter).
You can't use a user crontab formatted crontab for /etc/crontab or the fragments in /etc/cron.d and vice versa. A user formatted crontab does not include a username in the 6th position of a row, while a system formatted crontab includes the username and runs the command as that user.
#!/bin/sh at top)If your date is recently changed by a user or system update, timezone or other, then crontab will start behaving erratically and exhibit bizarre bugs, sometimes working, sometimes not. This is crontab's attempt to try to "do what you want" when the time changes out from underneath it. The "minute" field will become ineffective after the hour is changed. In this scenario, only asterisks would be accepted. Restart cron and try it again without connecting to the internet (so the date doesn't have a chance to reset to one of the time servers).
To emphasise the advice about percent signs, here's an example of what cron does with them:
# cron entry
* * * * * cat >$HOME/cron.out%foo%bar%baz
will create the ~/cron.out file containing the 3 lines
foo
bar
baz
This is particularly intrusive when using the date command. Be sure to escape the percent signs
* * * * * /path/to/command --day "$(date "+\%Y\%m\%d")"
sudo in cron jobswhen running as a non-root user,
crontab -e
will open the user's crontab, while
sudo crontab -e
will open the root user's crontab. It's not recommended to run sudo commands in a cron job, so if you're trying to run a sudo command in a user's cron, try moving that command to root's cron and remove sudo from the command.
Yes, rsync could stay quiet during disk read and while they have no packet to send...
You said. our firewall is configured to close idle connections that have opened for more than an hour but nothing about the continuous idle duration.
rsync process on both ends, reading whole files to search for difference between packets, based on checksums previously computed.
While there are no difference between files on both ends, they may be no exchange between both ends until differences are found.
There is a little graphic representing a single rsync run between my desktop and his backup:
In which we may see some seconds elapsed without datas:
TIME BLOCKS BYTES
IN OUT IN OUT
...
Jul 28 15:00:07 2013 449 41 23443 1526403
Jul 28 15:00:08 2013 0 0 0 0
Jul 28 15:00:09 2013 0 0 0 0
Jul 28 15:00:10 2013 143 182 21348 1123986
Jul 28 15:00:11 2013 112 142 6966 523326
Jul 28 15:00:12 2013 31 30 1942 1890
Jul 28 15:00:13 2013 30 28 1853 88038
Jul 28 15:00:14 2013 0 0 0 0
Jul 28 15:00:15 2013 57 66 3954 38301
...
As a workaround, you may use socket based ssh sharing:
First run a plain ssh for hanging socket and connection
ssh -M -o ControlPath=$HOME/.ssh/socket_test destHost ping -n localhost
Than in another window:
rsync -e 'ssh -e none -S $HOME/.ssh/socket_test' /src/file destHost:/dst/file
In this way, only one connection will be used for both ssh sessions. The ping will ensure (a lot of) continuous traffic, than rsync could work quietely, using same network connection.
Best Answer
Cron does not run in the same environment (with the same environment variables) as you do in an interactive login shell. I would guess it has something todo with that.
You probably either have an ssh-agent at your local computer which you forward to get access to 1.1.1.1 or you have something else set as an environment variable that you need to access the server.
You can set environment variables for cron by setting them in the cron file: