Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Suggestion for IOC log server
From: Ralph Lange <Ralph.Lange@gmx.de>
To: EPICS Tech Talk <tech-talk@aps.anl.gov>
Date: Tue, 24 May 2011 15:32:56 +0200
Hi Lana,

is there a particular reason why you want to run the traditional IOC log server?

Logging the real console output, e.g. using a package like conserver, has a number of advantages, including but not limited to the ability to log the boot process before the kernel, the network, and EPICS start up, seeing what commands people are typing at the IOC console, and being able to see error messages the IOC prints when it has network problems.

(Such a package can also do authentication for console access, allows multiple users to connect to one console, behaves reasonably when used with logrotate, adds time stamps to the logged output, etc.)

Cheers,
Ralph


On 24.05.2011 14:33 Abadie Lana wrote:


Hi all,

Our environment : Linux RH5.6, 64-bits

I would like to make a change in the iocLogServer.c and in particular to always force the close and open of the log file when the IOC log server catches a SIGHUP.

Currently it checks the file name is not the same one to perform the action :

L 908  if (strcmp(ioc_log_file_name, pserver->outfile) == 0)

Why is this a problem?

We are using logrotate in our system. We tried several scenarios but no way to make it work properly without using a full script. I described the different case we tried.

1)      Simple log rotate configuration (log file being moved, compressed and new one with the same name is created). The iocLogServer still points to the log file being moved and SIGHUP does not affect (because of the check no change on this variable). As a consequence the new file with the same name is always empty.

2)      Then I tried copytruncate, copy with a command to empty file : here the problem was the size always grewing until the file limit, the iocLogServer was always dumping its buffer (which was non human readable characters).

We also explore this EPICS_IOC_LOG_FILE_COMMAND but without success, still the same issue as we want to keep the same path.

Also we didn’t want to restart the iocLogServer each time we logrotate...

So the simplest solution I came up with was to remove this check. If this check is really needed, a flag can be added at start up of the IOC log server to see if one wants to force the update

So thanks for your comments/feedback and I would appreciate if IOCLog gurus can give their feedback on that issue...I may have miss something here on the reason of the check and request

Br

Lana

 




Replies:
Re: Suggestion for IOC log server Williams Jr., Ernest L.
References:
Device Support for Nemic Lambda Power Supplies Anthony Andrews
Re: Device Support for Nemic Lambda Power Supplies Eric Norum
Suggestion for IOC log server Abadie Lana

Navigate by Date:
Prev: Re: vxWorks network problems Steven M. Hartman
Next: Re: Suggestion for IOC log server Williams Jr., Ernest L.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Suggestion for IOC log server Abadie Lana
Next: Re: Suggestion for IOC log server Williams Jr., Ernest L.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·