we're having some issue on a SUN 5.8 machine.

first of all, the server is on his network (i.e. 10.x.x.x) and we can login using an ssh server which is on another network (196.x.x.x), so there're firewalls openings, in the middle, which allow us to connect.

I can login to this machine, switch to application user and, when I try to do a cat or to vi a log file, session hangs and, after a while, server kicks me off. Same behaviour when I cat or vi with my user. tail. more and grep work fine swap partition is 1% used

We had a similar issue, in the past, but at that time a faulty disk was found and, after its replacement, all worked fine. This time, SUN engineer says that all seems fine. Other people, connecting from other networks or from the same 10.x.x.x network, are not able to replicate the issue (means, they can cat and vi the files) so they're guessing is something related to the connection.

last night we also rebooted the server, due to a fan replacement, but the issue still occour...

any idea? thanks

  • Is it one specific file? Is the log file something like a webserver log file that "outsiders" can cause data to be written to? Does it start then hang? There have been attacks where specific terminal control characters are requested in filenames, these get logged in the log as 404s, then when someone tries to cat the file, the terminal control characters allow the attacker to execute commands or otherwise cause problems. See securityvulns.com/news/TERMINAL/control.html for some examples – DerfK Apr 14 '11 at 15:13

Once I had a faulty network card that did not pass certain traffic pattern. The only solution was to replace it.

Try to see what cat process is doing when the file is opened and the cat command is frozen. Use ktrace or strace to see in which syscall is waiting.

| improve this answer | |
  • interesting.. I used truss, since strace is mainly for linux env., and forwarded the output to the SUN engineer (including the suggestion to check the network cards) thanks a lot – rpiga Apr 14 '11 at 14:35

If there is a VPN involved somewhere between the 196.x.x.x and 10.x.x.x networks, the issue may be a MTU issue. One end is sending a packet which is larger than the other side can handle.

For some reason this seems to affect DSL connections more than other types.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.