From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
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
Steps to Reproduce:
1. create the following perl script as $HOME/kernel_panic.pl:
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.
note that this use of open in perl is not that common
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).
The oops would be from EIP __audit_get_target+0x1f6 in a Beehive-built
kernel. The +0x1ee offset I wrote in comment #1 was from a test build
using my local (older) compiler.
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 ***
*** Bug 143866 has been marked as a duplicate of this bug. ***
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.