Re: Suggestion for IOC log server

["Williams Jr., Ernest L." <ernesto@slac.stanford.edu>]

Hi
Is this the same as procServ

Sent from my iPhone

On May 24, 2011, at 6:34, "Ralph Lange" <Ralph.Lange@gmx.de<mailto:Ralph.Lange@gmx.de>> wrote:

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