[nos-bbs] don't do this with jnos

[(Skip) K8RRA]

I'm posting this to help others avoid my pitfall.
Be careful when you set "nice" for jnos.
First - it doesn't seem necessary.
Second - it severely disadvantages everyone when you set it badly (like
me) at a very high priority (-15) for jnos.

The background is like this...
I wanted to determine how much response time was jnos and how much was
system.  To change the system I used nice to change the scheduler.  I
discovered that jnos uses a trivial amount of CPU and the scheduler
priority really made very little difference in how quickly jnos
responded.

Until tonight.

I returned home to find the GUI VERY slow to respond to anything.
Typical of an overloaded system.  The system monitor showed jnos to be
using 17% user and 76% system CPU cycles - all others were trivial.  It
showed jnos to be doing this for the past (about) 1-1/2 hrs constantly.

The jnos sysop console was locked up and did not accept input nor did it
repaint the terminal - the clock was frozen at 8:24pm.  However while
sysop was frozen I was successful with a telnet session as a user on
another console.  In my session I was able to read email, display netrom
nodes, and the like.  I don't know if jnos responded to any of the RF
links I have active.

To stop jnos I started gdb but did not issue the "continue" command.
The system returned to normal at that time with jnos suspended.  At this
point in time I am lost with the issue of what to do next...

So I simply asked gdb for a stack list in the hope it would mean
something to anyone who cared to look - it is attached as a txt file.
It looks pretty short to me, and unremarkable...

And here is the rest of the story (ala Paul Harvey).  Around mid
afternoon a friend asked to chat on 20m so I powered down the TNC and
changed frequency on the radio and we chatted a while.  After that I did
not restart the packet station I have on that radio.  Tonight after the
stack list I told gdb to continue jnos and the system did return to the
same state as I found it in an hour ago.  I followed that by resetting
the radio and powering up the TNC --> AMAZINGLY the system returned to
normal and jnos is now again a trivial CPU user as usual.  You see I
caused the problem by:
 1) messing with nice
 2) choking jnos port off by shutting down the TNC without shutting down
the jnos port.
The sysop screen is running again, and sysop commands are responded to.

No the "No space!!" fault did not appear.

Here is the lesson I learned:
If the RS-232 path to a TNC becomes non responsive, jnos can hang.  It
probably has a buffer chock full of stuff with no where to go.  This is
something to use as a diagnostic tool.

More importantly, as an operator shut down the port before turning off
the hardware.

For the moment life seems to have returned to normal from fubar.  We
will see what tomorrow brings because I have not rebooted or restarted
anything.  That's my story and I'm sticking to it...:-)

73
de [George (Skip) VerDuin] K8RRA k
-------------- next part --------------
info watchpoints -- Synonym for ``info breakpoints''
info win -- List of all displayed windows

Type "help info" followed by info subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) info proc
process 3285
cmdline = './jnos2.0e3a'
cwd = '/jnos'
exe = '/jnos/jnos2.0e3a'
(gdb) info program
        Using the running image of attached process 3285.
Program stopped at 0x110402.
(gdb) info stack
#0  0x00110402 in __kernel_vsyscall ()
#1  0x00ba1353 in __write_nocancel () from /lib/libc.so.6
#2  0x080b361c in asy_tx (dev=0, p1=0x8afd538, p2=0x0) at unixasy.c:930
#3  0x0809491e in _kicker (func=0x80b34cc <asy_tx>, iarg=0, parg1=0x8afd538,
    parg2=0x0) at ksubr.c:116
#4  0x00b18c24 in makecontext () from /lib/libc.so.6
#5  0x080b34cc in pasy (asyp=0x0) at unixasy.c:879
#6  0x00483700 in ?? ()
#7  0x00000000 in ?? ()
(gdb)