[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

console reinitialization

William P LePera lepera@us.ibm.com
Fri, 12 Jul 2002 13:24:45 -0700 (PDT)


Two questions for the group, concerning conserver 7.2.2 and the automatic
console reinitialization:

In one case, I have conserver configured to access a console with the pipe
syntax, where it executes a command, instead of connecting to a terminal
server or serial port.  Without conserver, if the command fails, it prints
a message and exits.  With conserver running, the message repeats over and
over, until I kill the conserver daemon.  The conserver log file shows the
following, repeating over and over:

conserver (14198): lost carrier on c67rp01 (/dev/pts/2)! [Fri Jul 12
13:02:35 2002]
conserver (14198): c67rp01: automatic reinitialization [Fri Jul 12 13:02:35
2002]
conserver (14198): lost carrier on c67rp01 (/dev/pts/2)! [Fri Jul 12
13:02:36 2002]
conserver (14198): c67rp01: automatic reinitialization [Fri Jul 12 13:02:36
2002]
conserver (14198): lost carrier on c67rp01 (/dev/pts/2)! [Fri Jul 12
13:02:38 2002]
conserver (14198): c67rp01: automatic reinitialization [Fri Jul 12 13:02:38
2002]
conserver (14198): lost carrier on c67rp01 (/dev/pts/2)! [Fri Jul 12
13:02:39 2002]
conserver (14198): c67rp01: automatic reinitialization [Fri Jul 12 13:02:39
2002]

...and so on.

Is there a way to disable this automatic reinitialization, or configure as
to not to automatically try to "up" a console that has gone down?  In this
scenario, I'd like to simply display the message and exit.

The second case deals with an issue with the Equinox ESP terminal server.
The ESP installs software that makes it's serial ports look native to the
host OS.  Under linux, the cu command is used to access servers connected
to these ports.  Normally, if a server is rebooted, the cu command exits,
terminating the session.  Under conserver, the cu command exits, but then
is restarted again, restoring the connection.  So far, so good, right?  The
problem, though, is when the connection comes back, it's in spy mode, and
you don't realize this until you get the server's login prompt.  It appears
that keystrokes entered before the login prompt are just ignored.  After
the prompt is displayed, you get the conserver message "[no, user root
already attached]".  There's only the single connection that's running, so
the original one isn't hanging around.  Is it possible that the initial
session that was killed on the reboot might still be active when the new
session starts, forcing it (the new connection) into spy mode?  AND, is
there a way around that?

Thanks,

Bill LePera
IBM Server Group
Poughkeepsie, NY