From root@bgrsvr-y.badgergroup Wed Dec 17 08:45:01 2008
Return-Path: <root@bgrsvr-y.badgergroup>
X-Original-To: root
Delivered-To: root@bgrsvr-y.badgergroup
Received: by bgrsvr-y.badgergroup (Postfix, from userid 0)
id D793CF4A68; Wed, 17 Dec 2008 08:45:01 +0000 (GMT)
From: root@bgrsvr-y.badgergroup
To: root@bgrsvr-y.badgergroup
Subject: Cron <root@bgrsvr-y> root sh /home/badger_fruit/data/private/photo-backup/backup-script
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20081217084501.D793CF4A68@bgrsvr-y.badgergroup>
Date: Wed, 17 Dec 2008 08:45:01 +0000 (GMT)
/bin/sh: root: command not found
From root@bgrsvr-y.badgergroup Wed Dec 17 08:59:02 2008
Return-Path: <root@bgrsvr-y.badgergroup>
X-Original-To: root
Delivered-To: root@bgrsvr-y.badgergroup
Received: by bgrsvr-y.badgergroup (Postfix, from userid 0)
id 67DE7F4A68; Wed, 17 Dec 2008 08:59:02 +0000 (GMT)
From: root@bgrsvr-y.badgergroup
To: root@bgrsvr-y.badgergroup
Subject: Cron <root@bgrsvr-y> sh /home/badger_fruit/data/private/photo-backup/backup-script
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20081217085902.67DE7F4A68@bgrsvr-y.badgergroup>
Date: Wed, 17 Dec 2008 08:59:01 +0000 (GMT)
rsync: failed to set times on “/home/badger_fruit/lan/backup/.”: Permission denied (13)
rsync error: some files could not be transferred (code 23) at main.c(1031) [sender=3.0.2]
This is odd - the script seemingly runs OK (ie the files are copied)
The cron.d job is (ls -l):-
Code:
-rw-r–r-- 1 root root 89 Dec 15 19:47 badger
contents:-
Code:
#!/bin/sh
59 * * * * root sh /home/badger_fruit/data/private/photo-backup/backup-script
The file badger should not have a #!/bin/sh line. It should contain only
one line, the spec for the job. Remove the #!/bin/sh. It’s not a shell
script. It’s a crontab file.
Nonetheless your job ran and rsync is complaining it cannot set the
time on the destination directory. That may be due to the filesystem you
are writing to, is it NTFS? If you want to prevent such messages from
going to email, send them to the log with 2>&1 after the >> $LOG
> >
>
>
I can not comment on all you show, but the above seems to be strange.
where is the #!/bin/sh coming from? That line is not a crontab entry at
all. never mind, it will be seen as a comment by cron, but it is still
strange to me.
Reading through several man pages I think that the word ‘root’ in that
entry should be omitted. The user goes omly in a crontab entry if it is
the system crontab file (/etc/crontab).
It is an NTFS FS I am copying the data to, it’s mounted as CIFS and I
can read and write to it no problem from the ‘source’ machine for other
things (ie cp, mv etc)
Wierd but not show-stopping I guess.
I’ll see how these changes pan out; thank you all for your help!
No, don’t remove the root. A cron.d file needs a 6th column specifying
the user account to run as. There was nothing wrong with that. The error
was a side-effect of the first line I think.
Now you will probably find that there are complaints in /var/log/cron
about user sh not found.
Trust me, I have several cron.d files and they do have a user name in
the 6th column.
And in fact a cron.d file can have multiple lines, I lied a little. But
all of them should be job spec lines, no #! stuff.
PS: Here is the proof, in man cron:
> Cron also searches for /etc/crontab and the files in the /etc/cron.d
> directory, which are in a different format (see crontab(5)).
Sorry about that. I searched for it but only found ‘the system crontab
file’. I still do not quite understand where the crontab.d is for. But
taht is due to the fact that we hadn’t it twenty years ago lol!
/etc/cron.d is for local extensions to the vendor supplied /etc/crontab.
By putting jobs there, they can be identified as something to be carried
over when upgrading. Also you can divide up jobs into logical groupings
by file instead of adding everything to one big crontab and having to
insert dividers like:
> # the next 4 jobs are for the foobar queuing system
Thanks for the explanation. This philosphy then asks for not touching
/etc/crontab at all, but to put your own root cron-tasks either in the
daily, weekly, monthly dirs (or also not?) but in crontab.d.
I read several man pages for cron, crontab, etc. but still couls not
find even that cron looks into the cron.d dir. Must take sme more time
for studying I think.
BTW I am trying to find out in a private conversation with badger_fruit
if he needs to do this as root. Rsync-ing from within his own home-dir
to another dir he owns, does not need root and could be done from his
own crontab.
It seems to be a trend among services these days to allow for a
directory of config files. You see this in apache’s conf.d, xinetd.d,
logrotate.d. Even modprobe is in the game with modprobe.d. A ls -d
/etc/*.d reveals a whole heap of directories.
I think that’s how I noticed cron.d. I saw it first a few years ago and
guessed its purpose.
[logged in as user badger_fruit on “target” server BGRSVR-X
(Suse11.0)]
cd /home/badger_fruit/data/
mkdir photo-mirror
su
vim /etc/samba/smb.conf
[edited to share the new “photo-mirror” folder]
[backup]
comment = photos-mirror
path = /home/badger_fruit/data/photos-mirror
guest ok = yes
read only = no
force user = badger_fruit
[save and close]
service smb restart
exit
[logged in as user badger_fruit on “source” server BGRSVR-Y
(Suse11.0)]
cd /home/badger_fruit/data/private/photo-backup/
chmod u+x backup-script
mv backup-script /home/badger_fruit/bin
su
umount //windowspc/share
vim /etc/fstab
[edited to point to //BGRSVR-X/Backup]
[save and close]
mount -a
exit
crontab -e
[edited to new location of script]
[save and close]
su
service cron restart
exit
rm backup-log
touch backup-log
I then watched the backup-log file with tail and at the job-start time,
it did it, NO ERRORS!
It must be because I was writing to a NTFS (booo). This is OK, as long
as I have a mirror of the photos SOMEWHERE!!
I think there were a number of (NOOB!) mistakes in my process, I
thought it would be as easy as dump a file in the /etc/cron.d/ folder
and it would be processed. Using the steps above worked for me.