jim_patterson@comcast.net wrote:
> There are some of us in an office who have been noticing lock-ups on
> our computers on a weekly basis. We are using linux as our desktop.
>
> We have snort monitoring traffic from our firewall. Snort it not
> showing anything targeting these computers. So my current conclusion
> is that someway somehow one of the internal computers is causing the
> denial of service.
>
> This started out sporadically over the last few weeks (1 per week out
> of 30), then in the last 24 hours 3 computers have had to be rebooted.
> They are usually just locked up and can't be accessed via ssh or gnome.
> When I have checked, I can ping the computer.
>
> Log /var/log/message doesn't seem to indicate anything is going on, it
> just stops whenever the computer locks up.
>
> I've thought there might be a bug somewhere in CentOS4 that is causing
> this, but haven't seen any postings indicating such. But we do have
> systems with the same distro version and they don't seem to be affected
> by this. I thought maybe it was something we were doing on the
> desktop, but when the file server started having problems also, I
> started wondering if maybe there was a problem another computer was
> causing.
> I am looking for a way to find why systems are hanging and if this is
> being caused by an attack on the linux boxes. Is there some cute way
> that script kiddy could be DOS'ing our computers (What would be the
> most likely point of attack?). Is there someway to monitor this
> without DOS'ing ourselves.
Systems which went down yesterday were
-One system which went down yesterday is strictly a smb server. This
system has not gone down since it was brought up in Oct of last year.
-The other two are smb server/clients and nfs clients and both are
running vmware.

Last month I had one server that hadn't gone down in 3 years go down
once during 3 straight weeks. It has now been up for 2 straight weeks.

Thanks for the replies. I have downloaded the latest stable kernel and
changed my sysctl settings
echo 1 > /proc/sys/kernel/sysrq

# /etc/sysctl.conf
kernel.sysrq=1

Hopefully I'll either fix the problem or find the problem.
I am concerned that this setting will adversely effect performance, but
I'll give it a shot for now.
I currently do not have another system to use as a tap, so I'll have
to wait on doing that. I'll also double check whether any of these
systems are unnecessarily booting into X.