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