Bug 147636 - cron fails to run user jobs and gives vague error message
cron fails to run user jobs and gives vague error message
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
: 168855 (view as bug list)
Depends On:
Blocks: 156322
  Show dependency treegraph
Reported: 2005-02-09 18:13 EST by Carl Speare
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2005-361
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-05 08:34:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Wrapper script, which is the entry cron calls. (24 bytes, text/plain)
2005-02-09 18:15 EST, Carl Speare
no flags Details
The script that wrapper.sh eventually executes to run the user job. (471 bytes, text/plain)
2005-02-09 18:17 EST, Carl Speare
no flags Details
the cron file for iom_user (289 bytes, text/plain)
2005-02-10 18:08 EST, Carl Speare
no flags Details
wrapper.sh - sent directly from the Linux system instead of Windows. (21 bytes, text/plain)
2005-02-10 18:12 EST, Carl Speare
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:361 qe-ready SHIPPED_LIVE Low: vixie-cron security update 2005-10-05 00:00:00 EDT

  None (edit)
Description Carl Speare 2005-02-09 18:13:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
We are seeing a strange behaviour in cron where it will fail to run jobs, log that the job wasn't run, and continue normally. However, the log offers no good hint as to why it is occurring. I will attach the proper items to give further guidance, but the log simply states "UNSAFE".

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a normal user (in our example, iom_user).
2. Create a script that does some stuff (ps, ls, kill, whatever).
3. Create a cron entry to run the script.


Actual Results:  The job never ran, and logged the following message:
Feb  9 17:55:01 zinc-inst crond[24812]: (iom_user) CMD (/users/iom_user/bea/user_projects/domains/iom_domain/scripts/wrapper.sh /users/iom_user/bea/user_projects/domains/iom_domain/scripts/stopIOM.sh /home/iom_user/iom_order_deploy/)
Feb  9 17:55:01 zinc-inst crond[24811]: (iom_user) UNSAFE (iom_user)

The wrapper.sh script just exec's $* in an attempt to fix this problem. (It failed, obviously.)

Expected Results:  The script should have run, and I should have noted a log entry showing success.

Additional info:
Comment 1 Carl Speare 2005-02-09 18:15:56 EST
Created attachment 110902 [details]
Wrapper script, which is the entry cron calls.

This is the wrapper.sh script that is called in the cron entry shown in the bug
Comment 2 Carl Speare 2005-02-09 18:17:02 EST
Created attachment 110903 [details]
The script that wrapper.sh eventually executes to run the user job.

wrapper.sh calls this script (as shown in the cron entry), which is what does
the actual work.
Comment 3 Jason Vas Dias 2005-02-09 19:00:28 EST
CRON refuses to run any job from a file that contains illegal
characters, so the file I need to see is /var/spool/cron/iom_user 
to tell you exectly why it is rejected.

Yes, CRON's error messages on rejecting CRON jobs have always been
singularly unhelpful - there is no easy way to fix this without 
fairly major code changes, which would not have been acceptable for
RHEL-4 - lack of error messages is legacy cron behaviour, and I 
hope to have an enhanced CRON with good error messages through QA 
by RHEL-4-U2 .

CRON considers a file UNSAFE that contains any characters not in this 
set will reject any crontab file containing them :
see man tr(1) for exact meaning of this character class set.

Note that \r (CR, ^M) is NOT a member of this set, so if 
/var/spool/cron/iom_user contains MS-DOS style CRLF line endings,
it will be rejected - see man dos2unix(1) .
Comment 4 Carl Speare 2005-02-09 19:32:40 EST
The full crontab entry, as requested:

32 18 * * 0-
6 /users/iom_user/bea/user_projects/domains/iom_domain/scripts/wrapper
.sh /users/iom_user/bea/user_projects/domains/iom_domain/scripts/stopI
OM.sh /home/iom_user/iom_order_deploy/
Comment 5 Jay Turner 2005-02-10 05:47:05 EST
Carl, probably would be best to attach it as an attachment so that Bugzilla
doesn't screw up the formatting.  As it currently stands, it looks like you have
CR at the end of every line, and I don't expect that's really the way it is in
your file.
Comment 6 Jason Vas Dias 2005-02-10 10:09:56 EST
Yes, please attach the complete file as an attachment.
Alternatively, you could cut and paste the output of this command into
the bug:
   # od -c /var/spool/cron/iom_user

Comment 7 Carl Speare 2005-02-10 18:04:38 EST
[root@zinc-inst ~]# od -c /var/spool/cron/iom_user
0000000   3   2       1   8       *       *       0   -   6       /   
0000020   s   e   r   s   /   i   o   m   _   u   s   e   r   /   b   
0000040   a   /   u   s   e   r   _   p   r   o   j   e   c   t   
s   /
0000060   d   o   m   a   i   n   s   /   i   o   m   _   d   o   m   
0000100   i   n   /   s   c   r   i   p   t   s   /   w   r   a   p   
0000120   e   r   .   s   h       /   u   s   e   r   s   /   i   o   
0000140   _   u   s   e   r   /   b   e   a   /   u   s   e   r   _   
0000160   r   o   j   e   c   t   s   /   d   o   m   a   i   n   
s   /
0000200   i   o   m   _   d   o   m   a   i   n   /   s   c   r   i   
0000220   t   s   /   s   t   o   p   I   O   M   .   s   h       /   
0000240   o   m   e   /   i   o   m   _   u   s   e   r   /   i   o   
0000260   _   o   r   d   e   r   _   d   e   p   l   o   y   /  \n   
0000300   0       6       *       *       1   -   5       /   h   o   
0000320   e   /   i   o   m   _   u   s   e   r   /   i   o   m   _   
0000340   r   d   e   r   _   d   e   p   l   o   y   /   s   c   r   
0000360   p   t   s   /   s   t   a   r   t   I   O   M   .   s   h
0000400   /   h   o   m   e   /   i   o   m   _   u   s   e   r   /   
0000420   o   m   _   o   r   d   e   r   _   d   e   p   l   o   
y   /
0000440  \n
Comment 8 Carl Speare 2005-02-10 18:06:52 EST
I've attached the script, since the od came out pretty bad.
Comment 9 Carl Speare 2005-02-10 18:08:04 EST
Created attachment 110950 [details]
the cron file for iom_user
Comment 10 Carl Speare 2005-02-10 18:12:35 EST
Created attachment 110951 [details]
wrapper.sh - sent directly from the Linux system instead of Windows.
Comment 12 Jason Vas Dias 2005-02-11 13:55:14 EST
I finally have time to give this bug my full attention . 
Yes, Jay - you are right - the problem is that 'safe_delim' does not
contain '_' . 

The job is actually executed , as shown by the  
    crond[24812]: (iom_user) CMD (...)
but its output is lost, because cron rejects the user name as being
an invalid mail recipient user name.

This seems very silly to me - sendmail is able to do its own 
validation of user names. I can understand attempting to strip
unallowed binary chars from the output, as this could cause problems
without proper mime encoding, but cron does not attempt to do this .

The short-term workaround is to set   'MAILTO=iomuser' 
in iom_user's crontab, and to create an alias of iomuser for 
iom_user@localhost in /etc/mail/aliases .

I'm now producing a fix, which will be to to disable mail recipient
name validation unless the 'CRON_VALIDATE_MAILRCPTS' environment
variable is set in /etc/sysconfig/crond, which I will try to get
into RHEL-4-U1 .

Comment 13 Jason Vas Dias 2005-02-11 16:27:40 EST
This is now fixed in vixie-cron-4.1-22_EL, which is now making its
way through QA into RHEL-4-U1 . Meanwhile, you can download it from:
Comment 14 Carl Speare 2005-02-11 16:49:06 EST
Thank you - it works. Better yet, your response time was phenomenal.

Thany you again.
Comment 15 Jay Turner 2005-02-14 07:23:06 EST
Adding to the U1 Blocker list.
Comment 23 Jason Vas Dias 2005-09-20 15:12:21 EDT
*** Bug 168855 has been marked as a duplicate of this bug. ***
Comment 24 Red Hat Bugzilla 2005-10-05 08:34:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.