Open rgbriggs opened 11 months ago
pcmoore
commented
11 months ago Quick silly question: does this system have a working RTC? There are a number of smaller aarch64 systems, e.g. RPi 4 and below, that do not have a RTC and I imagine one might see something like this before the system has a chance to sync the clock to an external source.
pcmoore
commented
11 months ago Quick silly question: does this system have a working RTC? There are a number of smaller aarch64 systems, e.g. RPi 4 and below, that do not have a RTC and I imagine one might see something like this before the system has a chance to sync the clock to an external source.
Nevermind, I just checked on one of my aarch64 systems with a RTC and I'm seeing a similar timestamp issue.
We should obviously look into this, but we should also be prepared for the idea that this may not be something we can resolve. We want audit up and running as quickly as we can on the system, if we can't move the clock initialization sooner in the kernel startup we may have to live with this as a known issue on some systems/arches.
First audit message, audit initialization, on aarch64, has zero-second timestamp. The msec counter appears to be running. It appears audit is initialized before the system clock.
Ex: audit: type=2000 audit(0.360:1): state=initialized audit_enabled=0 res=1 audit: type=1403 audit(1692710902.940:3): auid=4294967295 ses=4294967295 lsm=selinux res=1 audit: type=1305 audit(1692710990.312:85): op=set audit_enabled=1 old=1 auid=4294967295 ses=4294967295 subj=system_u:system_r:auditd_t:s0 res=1
Expected results: The problem was discovered because logwatch does not match these lines, expecting more digits in the parentheses. This assumption works elsewhere but not on aarch64.