cron not running any jobs 2

[eagertotry]

On a Solaris 5.8 box, cron.allow specifically has my username(oracle). Created following cron entry via crontab -e, just to test. There is no other entry in cron.

$ crontab -l
00,05,10,15,20,25,30,35,40,45,50,55 * * * * /usr/bin/echo "testing" >/tmp/testing.log 2>&1

The job doesn't seem to run. There is no testing.log created. /var/spool/cron/crontabs/oracle file exists with timestamp same as when I did crontab -e.

My Unix SA tells me there is a bug in Solaris8 if you use crontab -e via ssh. I can't understand the connection. I just logged into the box using a ssh client (telnet is not allowed in our environment) and ran crontab -e.

Any ideas?

 

[jaytco]

I would verify the the cron with crontab -l.
Verify the cron deamon is running 'ps -ef | grep cron'
Check your mail for oracle for any cron errors.
If cron logging is turned on, look in /var/log/cron to see if your cron was reported.

I have not heard anything about creating a cron entry with ssh that should cause errors.

 

[eagertotry]

Thanks for the reply. crontab -l was already checked. It was in my first post.

ps -ef confirms cron is running.
cron logging is on but I don't have access to the cron logs. I need to get the SA for the same.

I too, cannot think of any connection between cron and ssh but just thought to check if anybody ever heard.

Thanks

 

[vptl]

Try running just the command from shell w/o cron, see if that works...

 

[pmcmicha]

eagertotry,

Normally you do not have to use /usr/bin when calling the 'echo' command. Instead of using 'crontab -e' to edit your crontab, try this, it tends to work better and you always have a backup.

crontab -l > <login>.cron
vi <login>.cron
-- Make changes.
-- Save and exit with changes.
crontab <login>.cron

Test to see if it is working now. Also remember that cron can take at least a minute to update new entries. So allow yourself some time by checking the date/timestamp on the server and your crontab entry. I usually give myself a 2 minute window when testing so that cron picks up the changes I made.

 

[KenCunningham]

Check that you don't have an empty line in your crontab file. This causes cron problems.

 

[SBSaikia]

"...My Unix SA tells me there is a bug in Solaris8 if you use crontab -e via ssh. I can't understand the connection. I just logged into the box using a ssh client (telnet is not allowed in our environment) and ran crontab -e.
..."

Yes, there is connection with:
crontab + Solaris8 + SSH + BSM enabled (for server sensor etc).

Solution:
1. edit/modify the crontab on the system console.
2. enable telnet temporarily.

I suffered from this issue untill I migrated to Solaris 9.

Best wishes.....

 

[coffeysm]

Why do you try just to modify the file using vi? That is how I modify all of my crontabs using SSH. vi /var/spool/cron/crontabs/root

 

[sunixadm]

Hi,

I'm not aware of any probably with cron and ssh. We use ssh and edit cron tabs on a regular basis.

I have had similar problems with cron in the past and this is what works for us:

rm /etc/cron.d/FIFO
vi /usr/lib/newsyslog and comment line:
#/etc/init.d/cron start
add line
/usr/sbin/cron


Hope this helps!

-Joe

 

[eagertotry]

Thanks for your replies.

vptl - yes, the command works fine w/o cron
pmcmicha - I tried using both crontab -e and crontab <file>. Its the same result.
KenCunnigham - no blank lines in cron file.
Coffeysm - Not privileged enough to edit entries in /var/spool/cron/crontabs. I am not an SA or root.
SBSaikia - Exactly the reply I got from my SA. Is there any reference to it anywhere? Sunsolve? any FAQ? If you can point us to one, you deserve a star.
sunixadm - I myself am using ssh/cron on another host with solaris 8 without any problems.

My problem got resolved as the host in question got rebooted over memorial weekend. I am trying to re-create the problem but with no success. I guess then that there is no explanation for this behavior and restarting cron solves the problem. Only, we ordinary mortals need to beg SAs to d o the same every time and that's not something we like.

Thanks to all.

 

[vptl]

Interesting...see if cron was working properlly before reboot (/var/cron/log you may not have access to that log ) for other cron users, Could be the cron was confused before you was trying to use it.

 

[sunixadm]

Hi,

According to the document I found on sunsolve related to this problem, this is an issue with fsecure ssh.

Heres the text of the document:
Document Audience: SPECTRUM
Document ID: 4732421
Title: Using Fsecure SSH to login to Solaris 8 System corrupts crontab.
Update Date: Tue Aug 27 13:52:00 MDT 2002

--------------------------------------------------------------------------------

Bug ID: 4732421Synopsis: Using Fsecure SSH to login to Solaris 8 System corrupts crontab.Category: c2_bsmSubcategory: utilityState: closedPriority: Responsible Manager: Responsible Engineer: Description: When using Fsecure SSH to login to server, crontab becomes corrupt and cron
jobs fail. Crontab has a UID (first line of crontab.au) 4294967294.
This only occurs when BSM is enabled and .au files are subsequently created for
each id that has a crontab in /var/spool/cron/crontabs.Work Around: Use telnet or console to login, edit crontab (no real changes necessary), and
wq! out. This sets the UID back to a valid number.Integrated in releases: , Duplicate of: 4457028Patch ID: , See Also: 4457028, Summary: When using Fsecure SSH to login to server, crontab becomes corrupt and cron
jobs fail. Crontab has a UID (first line of crontab.au) 4294967294.
This only occurs when BSM is enabled and .au files are subsequently created for
each id that has a crontab in /var/spool/cron/crontabs.

 

[KenCunningham]

Sunxadmin. Thanks for that - have a star.

 

[sunixadm]

Thanks for the star!