In our case, this problem has turned out to be related to the laus package. After disabling this service, the server that had been crashing every other day has stayed up, and enabling it on other previously stable test machines resulted in them starting to crash every other day.
This package started getting included in a "minimal" installation as of RHEL 3 update 3, and the audit daemon is enabled by default. If you don't need it (if you didn't know it was running or what it was, then you don't need it) you can safely disable it and reclaim a bunch of disk space from /var/log/audit.d.
root@localhost# chkconfig audit off
root@localhost# service audit stop
root@localhost# ps -ef | grep auditd (make sure it's stopped)
It also involves a kernel module (named "audit"), which you may also want to disable. Doing so will prevent the userspace tools that support auditing from generating errors when they can no longer find /dev/audit.
root@localhost# service crond stop
root@localhost# service atd stop
root@localhost# rmmod audit
root@localhost# lsmod | grep audit (make sure it's gone)
root@localhost# echo "alias char-major-10-224 off" >> /etc/modules.conf
root@localhost# service crond start
root@localhost# service atd start
You could even go so far as to remove the laus package altogether.
root@localhost# rpm -e laus
Reports on the Taroon mailing list and Red Hat's Bugzilla indicate that other activities such as restarting Lotus Domino server have approximately the same effect as our nightly running of upcp. I don't think this is a problem with cPanel, other than it causes occasional system activity which seems to trigger whatever problem auditd has. Updated kernel and laus packages that resolve this issue should be out with update 4.
Ref:
[bugzilla] System running LAuS hanging regularly
[bugzilla] audit service on by default?
[bugzilla] cron and laus problem
[bugzilla] Kernel panic when stopping Lotus Domino 6.52
[taroon-list] Re: Kernel panics