Mailing List Archive

On Fri, Aug 26, 2005 at 05:08:35AM -0600, Ryan Kirkpatrick wrote:
> *) When I try and connect with the console client, even from the local
> machine, it takes 2-5 seconds for the connection to occur. This is even
> longer than it takes to SSH into the system in the first place. I have SSL
> turned off, and I have DNS resolution setup correctly. From 'top', it
> looks like a lot of CPU time is being used by conserver during the
> connection start up. The older versions of Conserver was nearly
> instantaneous on connection.

actually, you probably have ssl on, but don't realize it. if you run
'conserver -V' and see openssl in the options: section, you've got it.
the config you shared shows 'sslrequired: off', which just means it can
allow a non-ssl client to connect, but still offers it and tries to use
it. if you run 'console -E <console>' then you'll attempt a non-ssl
connection (which should be nice and fast). you can add an 'sslenabled
off;' to a .consolerc file (in a config block) if you'd like it off by
default (the console manpage talks about that file).

> *) More seriously, when I connect with '-A' to display the last ten lines,
> eight times out of ten, the last ten lines are displayed, and then console
> exits with the error 'console: FileRead(): SSL error on fd 3'. As I said
> above, I am not using SSL at all. Connections attempts without '-A' never
> fail.

this one i can't reproduce (yet, anyway). i didn't use your config
file, but, in theory, that shouldn't matter (and it would be kinda hard
to since i don't have useful serial ports on my box). what version of
openssl are you using? perhaps it's worth upgrading as a test? though,
i haven't seen issues like this at all...so, i'm shootin' in the dark
here.

Bryan
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Mon, 29 Aug 2005, Bryan Stansell wrote:

> On Fri, Aug 26, 2005 at 05:08:35AM -0600, Ryan Kirkpatrick wrote:
> > *) When I try and connect with the console client, even from the local
> > machine, it takes 2-5 seconds for the connection to occur.

> actually, you probably have ssl on, but don't realize it.

That was it! I did not realize that the 'console' client used SSL by
default, or even that SSL was compiled in (using Debian testing package
backported). Once I added '-E' connections sped up greatly! Thanks!

> > *) More seriously, when I connect with '-A' to display the last ten lines,
> > eight times out of ten, the last ten lines are displayed, and then console
> > exits with the error 'console: FileRead(): SSL error on fd 3'.
>
> this one i can't reproduce (yet, anyway). i didn't use your config
> file,

I did a bit more testing on this problem, and I can rule out OpenSSL as
the cause. I recompiled conserver and console w/o OpenSSL support, and
while I did not get the SSL error message on connect w/replay, it still
disconnected me after the replay.

Looking at the general logfile, it appears the conserver process I am
connecting to is generating a 'Signal 11' when I ask for a replay. So,
conserver is not just dropping the connection, but actually crashing.

I looked into the log files causing a crash on replay and the ones that do
not. I found the following:

*) If the end of the log file contains all data from the serial port
(e.g. error message from my router's console), then I can connect w/replay
w/o a problem. No crashes, no sudden disconnects.

*) If the end of the log file contains only log events (i.e. '^[-- .*]'
lines) of MARK and console up/down messages (e.g. there has been no input
from the serial port in a long time), then when I connect w/replay I am
disconnected after the replay and conserver crashes.

*) If the above log file has an attach AND a detach log event appended to
it (either via connect w/o replay, or via manual cut'n paste), then when I
connect w/replay everything works fine, no crashes, no sudden disconnects.

Where, the end of the file is the last 10-20 lines. Therefore, it looks
like the replay log parsing algorthim is choking on lines of only MARK and
console up/down messages at the end of log files. Hopefully this helps you
get closer to solving, or at least duplicating this problem.

Let me know if there is anyway else I can help in solving this problem.
Thanks. TTYL.

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------


_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

well, i've been trying to reproduce the problem. i'm failing to find a
logfile combo that'll trigger the error. would you be willing to send
me a copy of your logfile (or whatever portion is necessary) so i can
reproduce it on my system and track down the bug?

thanks!

Bryan

On Tue, Aug 30, 2005 at 08:20:26AM -0600, Ryan Kirkpatrick wrote:
> *) If the end of the log file contains only log events (i.e. '^[-- .*]'
> lines) of MARK and console up/down messages (e.g. there has been no input
> from the serial port in a long time), then when I connect w/replay I am
> disconnected after the replay and conserver crashes.
>
> Where, the end of the file is the last 10-20 lines. Therefore, it looks
> like the replay log parsing algorthim is choking on lines of only MARK and
> console up/down messages at the end of log files. Hopefully this helps you
> get closer to solving, or at least duplicating this problem.
>
> Let me know if there is anyway else I can help in solving this problem.
> Thanks. TTYL.
_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users

On Tue, 30 Aug 2005, Bryan Stansell wrote:

> well, i've been trying to reproduce the problem. i'm failing to find a
> logfile combo that'll trigger the error. would you be willing to send
> me a copy of your logfile (or whatever portion is necessary) so i can
> reproduce it on my system and track down the bug?

Such a log file is attached, it is from an unused (currently) port on my
console server. It does not matter which port it is associated with, as
all ports are showing this behavior. When it is the log file for 'port30',
the following is what occurs when I try to connect (i.e. console -A
port30):

[Thu Sep 1 05:28:39 2005] conserver (7524): conserver.com version 8.1.11
[Thu Sep 1 05:28:39 2005] conserver (7524): started as `root' by `root'
[Thu Sep 1 05:28:54 2005] conserver (7526): [port30] login rkirkpat@farstar.rkirkpat.net
[Thu Sep 1 05:28:54 2005] conserver (7524): child pid 7526: signal(11), restarting

Thanks for you help. TTYL.

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------

thanks for the logfile. it was the same as what i had crafted and i
couldn't get it to fail, so i figured that must be more os-specific. i
got onto a linux box and, wham, it crashed.

i've attached a patch for (what i can see now) is an obvious problem
(worked before the STRING type was changed around - but was bad form
nonetheless).

anyway, apply the patch to 8.1.11 and let me know if you continue to see
problems. you shouldn't.

Bryan

On Thu, Sep 01, 2005 at 05:32:32AM -0600, Ryan Kirkpatrick wrote:
> Such a log file is attached, it is from an unused (currently) port on my
> console server. It does not matter which port it is associated with, as
> all ports are showing this behavior. When it is the log file for 'port30',
> the following is what occurs when I try to connect (i.e. console -A
> port30):

On Sat, 3 Sep 2005, Bryan Stansell wrote:

> anyway, apply the patch to 8.1.11 and let me know if you continue to see
> problems. you shouldn't.

That fixed the log replay crashing of conserver! Yea! :) Thanks for your
effort in fixing this bug.

Unless you see a reason otherwise, I will submit the patch to the Debian
bug tracking system for the conserver packages. That way, other Debian
users at least will be able to find it easily, if not get it included in
the next Debian update of the package. TTYL.

---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------



_______________________________________________
users mailing list
users@conserver.com
https://www.conserver.com/mailman/listinfo/users