Last year, I received a message from a sysadmin friend in Toronto,
which included the following ...

>>  An important machine-room-only system panicked early Saturday
>>  morning.  I had not yet had my nose rubbed in the inane Linux
>>  default that the kernel hangs forever after a panic, rather
>>  than rebooting: fine for the machine on which someone is
>>  debugging the kernel, not so fine on a random desktop, utterly
>>  loony on an important machine-room system.  (In all cases I
>>  speak of the default; it's fair to be able to intentionally 
>>  make it hang on panic.)

And after thinking about it, I had to agree:  It _is_ silly not to
reboot after a kernel panic; at least for a critical system where
uptime is important, and we don't have the luxury of 24x7 coverage
(which we haven't, for many years).  There have been numerous times
when a cluster node has died during the night or over a weekend, as
well as a few times when some more critical resource (e.g. metadata
server for one of the PVFS clusters; or the head node for a compute
cluster) has died; and with nobody around to reboot, a resource has
stayed down for hours, or even a day or two.

It's easy (and, I think, strongly advisable) to change this:  Just
add "kernel.panic = NNN" to /etc/sysctl.conf, with a sensible value
for NNN.  (And do a "sysctl -p" after doing so, so that the change
will take effect on the running system.)  I'll be doing this on all
the systems for which I'm responsible, and I propose that we do it
on all of our resources.

(At least, I can't think of any reason _not_ to ...)