ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

Discrepancy in timestamps of seaudit events routed to syslog by selogrd

book

Article ID: 133002

calendar_today

Updated On:

Products

CA Privileged Access Manager - Server Control (PAMSC) CA Privileged Identity Management Endpoint (PIM)

Issue/Introduction

After setup of log-routing from seaudit to syslog and startup of the selogrd the very first time a lot of old seaudit events are flushed to syslog with unequal timestamps within each event, e.g.

...

May 20 15:21:43 s00 selogrd[27367]: 20 Aug 2018 23:29:56 F UPDATE GROUP eta 337 0 ADM s00.fr.net j ("l228") grou"ADM" ) 

...

In this case the event was put in seaudit on 20 Aug 2018 23:29:56 but was forwarded to syslog on May 20 15:21:43


It was expected correlating events of seaudit and syslog are in sync basically showing the same timestamps.

What is the reason for this behaviour and how to avoid the issue?

Cause

The data flows the following:

  • seosd writes events in seos.audit
  • when selogrd starts up (for whatever reason at some later time) it retrieves all events from seos.audit
  • selogrd puts a pointer in the ../log/logroute.dat file to the last event handled so that next time selogrd starts up it continues from this pointer on, i.e. only sends the latest events.


Under normal conditions the events from seos.audit and selogrd's target (here syslog) are in sync - hence events in both systems have the same time stamp.

However when selogrd was stopped while events arrive in seos.audit, and started at a later time then the relevant event's timestamp shows when this event arrives in syslog.

Environment

Release : any

Component : CA ControlMinder / PIM / PAMSC - Unix  Unix / Linux Endpoints

Resolution

If it is feasible , to avoid processing of the many old events from seaudit flooding into syslog upon the very first startup of selogrd, delete the seos.audit file before the startup having it recreated afresh with empty content.

In this case do the following: 

  • shutdown seosd and selogrd
    # secons -s ; killall selogrd  
  • in seos.ini confirm selogrd is started up automatically
    ...
    [daemons]
    ...
    selogrd = yes
    ... 
  • delete (or rename) the existing seos.audit file
    # rm -rf ../log/seos.audit 
  • startup seosd and selogrd
    # seload 
  • confirm in syslog that only recent events from seaudit appear  
  • timestamps of each relevant event in seaudit and syslog are in sync


Should the above approach not be feasible and it is desired to forward the old events from seaudit anyway, to speed up the processing of these temporarily increase in seos.ini


...

[selogrd]

...

; The interval (in seconds) between each poll of the log file by the

; selogrd daemon.

; Default Value: 5

Interval = 1

...

; Maximum number of log records scanned by the selogrd daemon without going

; to sleep.

; Default Value: 50

MaxSeqNoSleep = 500

...


After syslog is in sync with seaudit please reduce these values to defaults again to avoid high system load.



In case there are still issues, confirm if there is any obvious indication if selogrd was started.

Once selogrd starts or stops it will put these messages accordingly in syslog:

...

Jun 06 09:02:59 rh76.mydom.ca.com selogrd[20548]: selogrd initialization steps completed.

                                                       Starting audit data routing.

...

Jun 06 09:01:15 rh76.mydom.ca.com selogrd[20511]: Caught a SIGNAL -1 [SIGTERM]

Jun 06 09:01:15 rh76.mydom.ca.com selogrd[20511]: selogrd is going down

...

Please check syslog if e.g. selogrd was stopped which might explain why the seaudit events have not been processed.