CRON.D job makes errors


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):-


-rw-r--r-- 1 root root 89 Dec 15 19:47 badger

contents:-


#!/bin/sh
59 * * * *  root sh /home/badger_fruit/data/private/photo-backup/backup-script

the “backup-script” is:-


#!/bin/sh
LOG_FILE=/home/badger_fruit/data/private/photo-backup/backup-log

date >> $LOG_FILE
rsync -avz /home/badger_fruit/data/photos/  /home/badger_fruit/lan/backup/ >> $LOG_FILE

Any ideas?
The target for the rsync is a Windows PC, the share has “full control” enabled for everyone.

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).

The command ‘root’ can indeed not be found.

guys, thank you for the swift replies
i have:-

  1. removed “#!/bin/sh” from the ‘badger’ file
  2. removed “root” from the ‘badger’ file
  3. added the “2>&1” to the ‘backup-script’

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.

hiya

just a quick update:

[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.