1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 <2014> 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: procServ softIOC server - V2.6.0 released |
From: | Pavel Maslov <[email protected]> |
To: | Ralph Lange <[email protected]> |
Cc: | EPICS Tech Talk <[email protected]> |
Date: | Mon, 24 Feb 2014 16:32:37 +0100 |
Hi Mark,
On Mon Nov 12 2012 17:14:03 GMT+0100 (CET), Mark Rivers
<[email protected]> wrote:For this situation, conserver [1] is a *much* better suited application.
> I installed procServ 2.6.0 because I really want to use the timestamp feature on the log files. One important application for us is using procServ to run the "telnet" command to our terminal servers connected to the VME console port on vxWorks IOCs. This allows multiple users to connect to the VME crate, and produces nice log files. That vxWorks output previously had no timestamps, so it was hard to know when errors occurred.
(Which also does nice timestamps.)
But, however, procServ should be able to handle it.
This option never existed in the official procServ sources.
> However, procServ 2.6.0 seems to have a number of problems.
>
> - The command to exit procServ no longer appears to be configurable. Previously it could be configured with -Q. Now it appears to be hardcoded to be ^Q. However, ^Q is needed when logged into a vxWorks system for XON/XOFF control (type ^S to suspend output, ^Q to resume). We were previously setting -Q to ^E.
Also, the ^Q (quit) character is only caught and interpreted when the
child process is down, i.e. when you are not connected to the remote
vxWorks system. While the child is alive and you are connected, ^Q will
be forwarded to the child process.
Which means the -Q option, that never existed, does not seem necessary
in the first place.
I will look into this.
> - The timestamp output is totally mixed in with the output, making it very difficult to read (see below).
Which platform are you running procServ on?
The ^M characters look like being part of a telnet protocol.
> - The log file has ^M characters in it at the end of each line. This is not a new problem, 2.4.0 also had this problem.
I suspect this is an issue with the connection between the telnet client
(that you start as procServ child) and the terminal server on the other end.
Which would place it outside the scope of procServ.
Can you test with a simple non-telnet client (e.g. a shell)?
Thanks,
~Ralph
[1] http://www.conserver.com