[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
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