Linux commands not displaying
 

Having a weird issue, if I remote into the server and run a linux command that requires more than one page of displaying information then the command hangs or seems to appear to hang. For example if I run 'cat /var/log/messages' nothing comes back and seems to hang, if I run 'tail /var/log/messages' then it comes back fine with no hang. Anything less than page will display the information anything more than that will seem to hang and do nothing.

But when I say hang its not like the process hangs because when I open another session and look for the process it isn't there any longer.

If I run the commands directly from the console there are no issues at all. Has anyone ever ran into something like this in the past?

I appreciate your help,
Best Regards,

Doug

May be it is waiting for network transfer. Also what are you using for remote session?

Using SSH currently with PUTTY, but its not a problem with PUTTY as I can connect to other servers and run commands with no issues, just seems to be to this one linux server. Like I stated if I run a command thats displays less than a single page of information it works fine. Example: df to display the filesystems is fine but if I use the top command nothing will show up, strange behavior for sure.

Dumb question, but is cat working properly? Are there other examples of commands where this is a problem? What if you use more or if you perform:Perhaps this is a situation where cat is directing to stdout and since you're remotely attached, you are not stdout. I'm not too keen on the server:0.0 notations, used to use that all the time back in the days of the Vax and attaching to a mainframe from a terminal. But there are notation ways to determine your particular X display number/address and then use that either as part of a command or issue a general X setting to cause the redirection of things like stdin/stdout for situations where you are a remote terminal.

Another option is if you are using ssh is to use the -X or -Y flags.

EDIT: I see that you are using ssh, so try the -X or -Y flags when you ssh over and see if that changes things.

Is /var/log/ a network (NFS?) mount?
in terminal >
will show you.
Are /var/log/messages being rotated? It could become quite large if it's not.
How's your ISP connection speed? High bandwidth?

I came across some project notes in a google search from a few years back. There was this long discussion between project members about the differing modes of terminal communication and how some of them were failing with their program. They changed some of the character translations somewhere to adapt to what the terminal driver was doing. Much of their problem pertained to the return key and the KP return and the differing translations encountered.
They specifically mentioned special problems when exceeding a single page of display.

This might be relevant. Using a different terminal communication invokes different character translations. One of them may be badly interacting with your local program, which causes it to respond in a way that the other program interprets as EXIT.

Consider what happens when the less command fills the page and displays the bottom line as a command line. It may use ESC sequences, or other terminal codes. Your network may not be entirely transparent to them. With cat and tail, it is harder to see what they would do.

You will have to get some capture program in between the target and your remote that captures the communication of both without affecting them.

Make some test files of half page, one page, and two page lengths. Use these for tests to isolate the communication problem from any /var/log/ considerations.
>> tail /var/log/messages > test_half
>> cat test_half test_half > test_one
>> cat test_one test_one > test_two
The remotely try cat, more, less, and other ways to display the files. This should narrow the possibilities.