|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||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|
|<== Date ==>||<== Thread ==>|
|Subject:||Suggestion for IOC log server|
|From:||Abadie Lana <Lana.Abadie@iter.org>|
|To:||EPICS Tech Talk <firstname.lastname@example.org>|
|Date:||Tue, 24 May 2011 14:33:43 +0200|
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