From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225
Description of problem:
certain perl constructs (well, underlying system calls i'm sure) can
easily cause kernel panic when run under cron but NOT when run from
the command line. this type of kernel panic is, of course, extremely
difficult to trace.
Version-Release number of selected component (if applicable):
Linux 2.4.21-20.EL i68
How reproducible:
Always
Steps to Reproduce:
1. create the following perl script as $HOME/kernel_panic.pl:
#!/usr/bin/perl
open ('kerel_panic');
obviously make this file executable
2. add a crontab line similar to following to run this program
* * * * * $HOME/kernel_panic.pl
3. sit back and watch a userland crontab entry not only panic the
kernel, but make it almost impossible to reboot and, therefore, debug.
btw. i'd reccomend cron'ing the above at a specific time so as NOT to
render your machine useless
Actual Results: instant kernel panic
Expected Results: nothing - the file does not exist so the program
should have simply failed.
Additional info:
note that this use of open in perl is not that common
open 'file'
normally you'd see
open FILE, '< file'
or something. however this shoud NOT panic the kernel!

I reproduced this crash under 2.4.21-27.EL (U4) by queuing the cron job
using the "crontab -u $user -l" command (and waiting for the minute to
roll over). The oops is in the "audit" module at __audit_get_target+0x1ee.
The logical bottom-of-stack is syscall_trace_leave+0x58.

If you don't heed the advice of scheduling the cron job for a specific
time (for a "one-shot" run), then your test system will continue to panic
during each reboot. In order to recover, boot with "init=/bin/bash" added
to the kernel args, use "fsck" to fix up file systems, remount the root
file system (presuming it contains /var) read-write (with the command
"mount -n -o remount,rw /"), and then run "crontab -u $user -r"
to recover (and then reboot).

A fix for this problem has already been committed to the RHEL3 U5
patch pool on 15-Nov-2004 (in kernel version 2.4.21-25.1.EL).
To work around this problem before U5 is released (a few months
from now), please disable auditing with the following commands:
chkconfig audit off
service audit stop
*** This bug has been marked as a duplicate of 132245 ***

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.
http://rhn.redhat.com/errata/RHSA-2005-043.html

Note

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