Automic Workload Automation

Expand all | Collapse all

v12.1 service manager does not rotate trace files.

  • 1.  v12.1 service manager does not rotate trace files.

    Posted 12-08-2017 05:10 AM

    In the ucybsmgr.ini file, I have the following trace settings:

    [TRACE]
    file=/var/uc4/servicemanager-server/SMgr_EXP2_trc_##.txt
    trccount=100
    tcp/ip=9
    cmd=9

    In /var/uc4/servicemanager-server, I see the following files:

    SMgr_EXP2_log_00.txt
    SMgr_EXP2_log_01.txt
    SMgr_EXP2_log_02.txt
    SMgr_EXP2_log_03.txt
    SMgr_EXP2_trc_##.txt

    It seems that the log files are being rotated but the trace files are not. Is this a known bug?



  • 2.  v12.1 service manager does not rotate trace files.

    Posted 12-15-2017 09:46 AM

    Hi Michael,

    I did a quick search through our system for any errors like that, but didn't find anything.

    I would recommend opening a ticket.

    All the best,

    Cameron



  • 3.  v12.1 service manager does not rotate trace files.

    Posted 12-15-2017 10:06 AM
    Paul_Smith_9332: Thanks for checking. I opened INC00217296 for this.


  • 4.  v12.1 service manager does not rotate trace files.

    Posted 12-15-2017 10:21 AM

    Actually none of the Automic components rotate the trace files as it is the case with logfiles. Traces - as soon as switched on - will write to the same file until switched off.

     

    However there is one exception: Since v12 the memory trace can be defined with a defined size, where a trace of a defined size will be written as soon as a specific u-number is occuring within a serverprocess, but that is for the Automation Engine only, and is also not really a fileswitch.



  • 5.  v12.1 service manager does not rotate trace files.

    Posted 12-15-2017 10:44 AM

    Karin Wasinger wrote:

    Actually none of the Automic components rotate the trace files as it is the case with logfiles. Traces - as soon as switched on - will write to the same file until switched off.

    This is not correct. The Automation Engine rotates both logs and traces whenever logging is changed or the process stops and restarts. It renames old logs & traces and begins writing new ones.

    The SMgr documentation clearly states that the service manager works the same way.

    [                                                   TRACE                                                   ]                                              
    file=                                                        

    The path and the file name of the trace file.

    Any file name for a text file with several place holders for current system information:

    $$ is replaced by server process type (WP or CP) in the context of a server process.

    *  is replaced by the three-digit process number in the context of a server process.

    ## is replaced by 00 after the available trace files' corresponding numbers have been raised by one during startup of a trace.

    *** is replaced by the three-digit abbreviation of the respective unix version (unix agent only).

    ...

    Default:                                                                  ../temp/trace_##.txt

    (Emphasis mine.)



  • 6.  v12.1 service manager does not rotate trace files.

    Posted 12-15-2017 11:15 AM
    I think we have a misunderstanding of what rotation means. By rotation, I simply mean the process of moving old files out of the way before new files are written. I realize that the Service Manager does not rotate files automatically based on predefined criteria like file size or elapsed time. However, it does (or should) rotate the files when the program is stopped and restarted. This is what is not working correctly. The program rotates logs files, but it does not rotate traces. In fact, it does not even name the first trace file correctly.


  • 7.  v12.1 service manager does not rotate trace files.

    Posted 01-09-2018 04:56 AM
    Problem PRB00217357 has been opened for this bug.


  • 8.  Re: v12.1 service manager does not rotate trace files.

    Posted 06-07-2018 11:12 AM

    I confirmed that this problem is fixed in v12.1.2.