Well, this is what happens when I go on vacation and look at a problem 2
weeks after the fact. Maybe I won't go on vacation any more and visit my
g'kids. Naaah!!
I was actually able to reproduce the problem later. I was watching the
trace file on a test system and after repeated telnet connects and
disconnects, I didn't see anything change on the file. The next
day,however, I stopped TCPIP with a CP EXT command and that flushed the
buffer to the trace file. The mdisk containing the trace file was
formatted to 4k blocks and there, apparently, just wasn't enough stuff
ready to be written out. After the file was closed, it only contained 1,
4k block. Still, as Alan said in a subsequent append, the destination of
the trace output seems like a strange place to put TELNET console output.
Jim
At 11:57 PM 1/5/2006, you wrote:
A correction to the story below: TCPIP did not stop working at any
time. It dealt gracefully with the full A disk. Also, I didn't have to
guess what happened; TCPIP announced it quite clearly in it's console:
05/12/23 08:56:29 TCPIP CORNELLC: DMSERD107S DISK A(191) IS FULL
05/12/23 08:56:29 TCPIP CORNELLC: ERROR WRITING FILE "TCPIP PROB0001
A1" ON DISK - OUTPUT HALTED
Our question is what caused normal TCPIP console output, specifically
telnet connection opened and closed messages, to go to the trace file and
not to the virtual console. (Some output, including start of day
messages, continued to go to the virtual console.) This output started
going to the trace file and not the console right after Jim issued
NOSCREEN via NETSTAT OBEY. The documentation says NOSCREEN should only
affect trace output, and Jim was unable to reproduce this behavior when he
tried this recently on a test system. Could this be a bug? Or is there
something we might have accidentally done to cause this?
Mark
At 04:06 PM 1/5/2006, Jim Bohnsack wrote:
The suggestion here to put 'NOSCREEN' and 'FILE fn ft fm' in the PROFILE
TCPIP file to prevent a run away trace seemed to be so good that we
decided to put it in even tho it was just a few days before I left town
for the Christmas break. We normally run with the TCPIP console
secuser'd to the id running PROP and with sysoper privileges and didn't
notice that when I put these in place with an OBEYFILE command, that
nothing was being sent to the id running PROP. About a week after I left
town, TCPIP stopped working because the file that was pointed to with
'FILE fn ft fm' filled up the TCPIP A-disk even tho we were not tracing
anything. It's just the normal telnet session established type of
traffic. My counterpart here guessed what the problem was and changed
PROFILE TCPIP back, commenting out NOSCREEN and FILE. Everything is fine
now, but we are really puzzled. The trace statement was 'NOTRACE
ALL' which I thought meant don't trace anything and since nothing is
being traced, nothing would be put in FILE.
Mark Bodenstein ([EMAIL PROTECTED])
Cornell University
Jim Bohnsack
Cornell Univ.
(607) 255-1760
