Cron problem

Y

yacine

Verified User
Joined
Feb 9, 2006
Messages
10
I have DA version 1.26.6 and when I try to setup a cron job it don't work.
I log in as a user, I set this parameter :
*/15 * * * * /home/myuser/restore_demo.sh

When I excute the script with the command below in the console :
/bin/bash /home/myuser/restore_demo.sh
the script is well excuted but with cron not.

when I log as a user and try the command crontab -e I get this error: seteuid: Operation Not Permitted

Please help
 
Last edited:
My guess is that the suid bit on the crontab binary isn't set.
Do ls -l /usr/bin/crontab to see if that's the case. Is so issue chmod u+s /usr/bin/crontab as root.

HTH.
Ruben.
 
Thank you for your help but cron don't work again.
Now, when I do ls -l /usr/bin/crontab
I have :
-rwsr-xr-x 1 root root 29052 jui 12 2005 /usr/bin/crontab

I have made a small script yac.sh

#!/bin/sh
echo "cron is working" >> /home/myuser/tmp/recup.txt

and in DA cronjob :
*/5 * * * * /home/myuser/yac.sh


But no file in the tmp directory !
 
But does crontab -e work now after you set the suid bit?

Also check what you get when you execute the command from the commandline:
echo "cron is working" >> /home/myuser/tmp/recup.txt

Are you sure the tmp directory exists in the users homedir?

What's the output of crontab -l -u <username> ?

And last but not least: make sure the cron daemon is running.

HTH.
Ruben.
 
Yes contab -e is working.
When I execute the command from the commandline:
echo "cron is working" >> /home/myuser/tmp/recup.txt

I have a file recup.txt with "cron is working" write on it and is the tmp directory of the user.

When I excute crontab -l -u <username>, I have :

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (./data/users/myuser/crontab.conf.tmp installed on Mon Apr 17 14:06:27 200
6)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
*/5 * * * * /home/myuser/yac.sh
 
I have this :

[root@serv1 ~]# ps aux |grep cron
root 12696 0.0 0.0 5256 1084 ? S Apr01 0:00 crond
root 18678 0.0 0.0 4812 748 pts/0 S Apr01 0:00 grep cron
 
I have this :

[root@serv1 ~]# ls -l /home/myuser/yac.sh

-rwxr-xr-x 1 myuser myuser 57 avr 16 22:09 /home/myuser/yac.sh
 
For me also, I can give access at private email if you want to test by your self
 
Well I believe you when you say it doesn't work, but I'm just out of ideas. So having shell-access won't help. Sorry, maybe someone else has new suggestions.

Ruben.
 
Hello,

I logged in.. there is a dissociation between crontab and crond on this system. The yac.sh was not being run even though crontab -u username -l did output it as being present. Restarting crond did not fix it. There was no mention of it in /var/log/cron.

/var/spool/cron/* is where crond looks for the crons, but crontab was storing the data somewhere else (I was not able to find it).

I manually placed the crontab for that user in /var/spool/cron/username and restarted crond, and then everything worked fine. So there crontab is putting the crons in the wrong spot such that crond can't find them.

Possible solutions would be to find a different cron rpm with up2date or with rpmfind.net... I have not seen this before so can't say for sure of the solution.

John
 
That's very odd indeed.

From the man-page:
cron searches its spool area (/var/spool/cron/crontabs) for crontab
files (which are named after accounts in /etc/passwd); crontabs found are loaded into memory. Note that crontabs in this directory should not be accessed directly - the crontab command should be used to access and update them.
Click to expand...

It could be a version mismatch between the crontab and crond binaries.

Ruben.
 
Yacine, what OS Distribution are you using?

My own RPM based solutions put crontab files into /var/spool/cron, not /var/spool/cron/crontabs.

Here's a quote from man cron on one of my systems, running DA on RH-based linux:
Cron searches /var/spool/cron for crontab files which are named after accounts in /etc/passwd; crontabs found are loaded into memory.
Click to expand...
Jeff
 
Jeff, I'm using Fedora 3, the problem is solved when I do the things manually.

I am tempted to make an update to cron but I am afraid to have other problems.
 
Hello,

For anyone else who might encounter this problem... apart from actually fixing crond, you can create a cron file to fix things.
Create the following script:
Code: 
#!/bin/sh
cd /usr/local/directadmin/data/users
for i in `ls`; do
{
    if -e [ $i/crontab.conf ]; then
        crontab -u $i -l > /var/spool/cron/$i
    fi
};
done;
/sbin/service crond restart
exit 0;
and then add a cronjob in /etc/cron.d/yourfile to run this script every so often.. maybe hourly, up to you.

John
 
You must log in or register to reply here.
Back
Top