RE: Suggestion for IOC log server

[Abadie Lana <Lana.Abadie@iter.org>]

Hi Andrew
Thanks for your reply. 
Actually we are using logrotate based on the file size and not based on the time. In our set-up Logrotate is our software to manage log files.
What we do is we set an environment variable for the epics ioc log file size limit > logrotate file size + margin

Then we close and reopen the log file via SIGHUP-> size reset to 0 and etc.
So in fact we avoid usage of circulate buffer. But if it can be safely removed I would prefer then.
The EPICS_IOC_LOG_FILE_COMMAND works if the directory changes...which is not our setup...
One thing I don't understand is this sentence:

**** The only downside appears to be 
that the server code has to scan through the log-file looking for the write 
location if the name doesn't change, but I don't see that as a major problem 
myself.  Does anyone object to this?
*****

What do you mean?
In our case we put the full path the EPICS_IOC_FILE_NAME...


So just let me know how I have to proceed...


Ralph, regarding your question : I will definitely look at conserver toolkit. Thanks for the hint.
Many thanks
Lana
-----Original Message-----
From: Andrew Johnson [mailto:anj@aps.anl.gov] 
Sent: 25 May 2011 00:22
To: tech-talk@aps.anl.gov
Cc: Abadie Lana
Subject: Re: Suggestion for IOC log server

Hi Lana,

On 2011-05-24 Abadie Lana wrote:
> 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 :
>
> if (strcmp(ioc_log_file_name, pserver->outfile) == 0)
>
> Why is this a problem?
> We are using logrotate in our system.

The log server has its own version of logfile rotation, which was added in 
1996 by KECK (does KECK still use that feature — Kevin?).  I don't claim to 
understand it completely, but the the current behavior is that when it gets a 
SIGHUP it will execute the command given in the environment variable 
EPICS_IOC_LOG_FILE_COMMAND to get the name of the new logfile.  That might be 
something like this, which (in conjunction with a daily cron job run at 
midnight) would create a new log file in a dated directory:

date -u +/path/to/iocLog/%Y-%m-%d

If you want the latest log file to always be accessible at the same filename, 
you could arrange for the script that sends the SIGHUP to also create a soft-
link pointing to the new log file.

I don't see a particularly compelling reason to reject the change you're 
asking for though, does anyone else object?  The only downside appears to be 
that the server code has to scan through the log-file looking for the write 
location if the name doesn't change, but I don't see that as a major problem 
myself.  Does anyone object to this?

Note that the circular nature of the ioc log-files means that standard Linux 
logging tools could get confused when they hit the end/beginning point in the 
file, so this might not solve all of the problems with the log server.

You could also create your own simpler version of the log server that is 
compatible with logrotate and doesn't implement the circular behavior.  I also 
think maybe we should replace our own IOC logging system with one that is 
compatible with the modern remote logging packages that are now in fairly wide 
use.  Discussion and code contributions welcome...

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham