[nos-bbs] Background JNOS operation
Mark Phillips
g7ltt at g7ltt.com
Fri Feb 20 17:55:14 EST 2009
Screen geometry is your problem here.
Make sure you resize your terminal window to 80x24.
If you look carefully you'll find JNOS has respawned too.
I run my JNOS on my headless WRAP machine in the same manner as you
describe. It works flawlessly until I log in with the wrong terminal
size.
Mark
On Fri, 2009-02-20 at 13:58 -0500, George [Skip] VerDuin wrote:
> Greetings.
>
> The next step at K8RRA is to encourage JNOS to live peacefully in the
> background. A "headless" computer is the further target. Using
> "screen" as a detachable/re-attachable link to gain access to the sysop
> console almost works nicely. Also, jnos&screen seem to be just happy
> operating from a background process.
>
> Here is an interaction between jnos--screen that is misbehaving. When
> started as:
> ...# screen -d -m jnos ...
> the processes start up nicely and are happy until attaching for the
> *first time* with:
> ...# screen -r
> Wherein jnos issues the message "NOS PANIC Lost keyboard (-1/4)"
> followed by an automatic restart of jnos. The second killer is that the
> restart initiates "tun1" rather than tun0 [for an unknown reason] which
> kills the link from the new instantiation of jnos and the OS -- Fedora
> in my case. The "ifconfig" shows tun0 to be active and tun1 to be
> non-existant [another mystery].
>
> The non-detached jnos startup is very normal when started with:
> ...# screen jnos ...
> In both this case, and with the "-d -m" startup above, the manual
> detach-then-reattach sequence work nicely with no ill effects found
> here thus far...
>
> SO -- the question I pose is "why the PANIC?". The message originates
> from curses.c and I wonder why curses is bothered by attachment of the
> keyboard later than initial startup [but before the first character is
> typed]. Thus far, it seems to me I must revise the jnos code to
> suppress the panic, and perhaps fix the tun1/tun0 issue upon restart too.
>
> The more interesting question is "Has anyone found a work-around for
> this problem to avoid revising jnos source?".
>
> Cheers to all & 73.
> Skip
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
--
Mark Phillips, G7LTT/NI2O
Randolph, NJ
More information about the nos-bbs
mailing list