>> A process died and became a zombie process in a screen-session.
>> The process was irssi and thus not critical.
>> I tried to kill the zmbie-process without luck.
>
>zombies are undead, you can't just kill them, you need to find the
>process which created them and attack that instead.

Realized it! Thank you :-D

>> Thus I re-loged in and killed each ksh I ran.
>> Then I did a screen-x and my shell freezed.
>> I tried again to reconnect to the server but had no luck.
>>
>> I got not even a ssh-fingerprint from the sshd anymore (removed
>> known_host to check) but connections where accapted by sshd (nmap scan
>> and others showed "open"9 and the ssh-connections made to it NEVER
>> pinged out.
>>
>> Another server process using OpenSSL (silc) became NON-responsive too.
>> A field technican in the US went to the box and made a photo on which I
>> can see very strange symbol lines.
>> He was able to enter a username but the "password:"-field never
>> appeared.
>>
>> I triggered the bug as I pressed "ctrl-c" during the reconnection because
>> the connection was slow and I wanted to kill it (client-side).
>> Could this be a indication for a OpenSSL bug and if so: How could I
>> might trace or -trigger it again?

> I think the ssl thing is a red herring, it's probably not scheduling
> any processes. If you had just telnetted to port 22 it would have most
> likely just connected and not shown the usual banner. I've seen it
> before occasionally but not got any useful way to trigger it. It
> sounds similar to hangs some people have seen while rsyncing
> (especially with softdep) which points to a vm exhaustion problem
> of some kind..(there have been many changes in that area since 4.5)

Yes softdep was in use but that the softdep code is flawed is known.
But I did not tried to grep banners. Forgot about it.
I could not have imagined that this bug could hit the box so seriously.

>If you can break into ddb when this happens, trace/ps and maybe other
>things might help. Better still would be traces from -current if you
>can still provoke it there.

The OS got totaly corrupted.
gdb, su, sudo do segfault for example.
if I issue "login" the shell gets killed and no further login is
possible. But later my ssh died again and after that the server finaly
broke down. Beyond the point of what fsck can handle.
During auto-fsck the box reboots.

A good bug I'd say... ran into it now 2 times in less then
5 hours. And I have no clue why or how I triggered it.

>What anyone is meant to do with the information that you see "very
>strange symbol lines" without more description or seeing the photo,
>I don't know...

The technican reported that the login (localy) showed strange
charackters. He made a photo for me.
This is a transcript:
--
Login: root 
^[[12~^[[12~^[[13~^[[14~root
root
--
The 2nd and 3rd "root" where trials to get to a password prompt (which
never appeared).


Thank you very much Stuart for your hints.
If there is more I could tell you please do let me know.


Regards,
Gandalf

Reply via email to