System slows then stops 2

[rweir02]

I'm running SCO 5.0.4, with Progress 7.3E (I know it's old) and QAD 7.4. This morning I walked into a system that had hung it could about 3 attempts before I was able to bring the system back up and the databases started. The error message I found is:
vv_flush: I/O error 5 on fd1

Anyone have any ideas as to why this is occurring. It has happened before, but it is rare (about 2-3 times a year).
Users are not allowed into Unix, their log-ins take them directly to the QAD log-in screen.

Thanks

 

[pcunix]

Well, it sounds like a Progress error- it couldn't write data to a file descriptor it had open.

This could be an Progress problem, or it could be something else- see

http://pcunix.com/Unixart/slow.html

for a general start on troubleshooting this kind of thing.


Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[rweir02]

Tony

Thank you for your response, I will give the link a try.

Robin

 

[stanhubble]

This is definitely a progress v7 error

hth
stan
____________________

Kbase Id: 15406
Title: vv_flush : I/O error 5 on fd1
Creation: 18-Jan-1996
Modified: 10-May-1998

vv_flush : I/O error 5 on fd1
What is a vv_flush?
In Version 7, the PROGRESS terminal interface changed. The version 6 interface was replaced with Vermont Views, a third party software package. This vv_flush error is generated by the Vermont Views code.
What does it mean?
The vv_flush:I/O error 5 on fd1 error means that a message was sent to the tty device, but the PROGRESS client was no longer attached to the tty. The fd1 refers to file descriptor 1, or standard out.
In Version 6, the same situation was reported with this message.
SYSTEM ERROR: I/O error 0 in writeit, ret 0, file(tty), addr <n>.
(290)
Should I be concerned about this error?
The vv_flush error by itself is harmless. It is only a symptom of
what might be another problem. You might want to analyze why you see
this error if it occurs frequently.
Reasons why I might see this error.
1- The user shut the terminal off and their _progres process never
received a HANGUP SIGNAL. This is often the case with users who
telnet to the UNIX machine through a PC software emulation package.
2- In Version 7.2, and 7.3Axx, there was a bug that caused a runaway
process when an _progres process did not get a HANGUP SIGNAL. This
bug is fixed in Version 7.3Cxx.
LJF
18-Jan-96
Progress Software Technical Support Note # 15406

 

[rweir02]

Stan

Thank you for the information, very useful.
Robin

 

[pcunix]

OK, knowing what Stan posted now, I'll bet you'll find a process (or processes) in ps that are not attached to a terminal (they'll show a ? in the tty column) and that are sucking cpu- you'll see the time column increase steadily.

Write a simple script to hunt these down and kill them until you can get to the root cause.

The script can run every hour or so (depends on how long it takes for these to become a problem). You can do a grep for the program name, look for no associated tty, and then kill it.
Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com