On 08/07/2018 06:36 AM, Kristján Valur Jónsson wrote:
aproppos incorrect time, I wrote a fake-hwclock service for centos, available here:  
https://github.com/kristjanvalur/fake-hwclock

Works great!

A pain to install when first building a system.  I cheated and remounted my drive on my notebook and copied that way.  I will do that in the future builds before I install the drive in the arm system.

I had to set permissions on install:

chmod +x install

You should add that to your instructions.

It would be great if this were an rpm in epel for ease of installation.  Or at least an rpm that I could wget from someplace then do a localinstall.

Also, consider offering this to chrony.  Miroslav may be interested.



On 5 August 2018 at 13:02, Robert Moskowitz <rgm@htt-consult.com> wrote:
I had to reboot a server this morning.  I was working on one box and bumped things I should not have...

Then I noticed my name server was not coming up real fast like normal.  So I get on the console and notice it is waiting for something to start.  It waited 3 min before giving up and getting everything else going.  So after it was up, I ssh in and checked the messages and found:

Dec 31 19:00:29 onlo systemd: Starting Security Auditing Service...
Dec 31 19:00:29 onlo auditd[499]: Started dispatcher: /sbin/audispd pid: 501
Dec 31 19:00:29 onlo audispd: No plugins found, exiting
Dec 31 19:01:59 onlo systemd: auditd.service start operation timed out. Terminat
ing.
Dec 31 19:03:30 onlo systemd: auditd.service stop-final-sigterm timed out. Killi
ng.
Dec 31 19:03:30 onlo systemd: auditd.service: control process exited, code=kille
d status=9
Dec 31 19:03:30 onlo systemd: Failed to start Security Auditing Service.
Dec 31 19:03:30 onlo systemd: Unit auditd.service entered failed state.
Dec 31 19:03:30 onlo systemd: auditd.service failed.


Ignore the timestamp.  This occurs before the network is up and chrony has not set the time.  Cubies do not have a battery RTC.

But I believe this is recent.  I had gone a LONG time without updating and applied some 180 rpms updates (in careful batches).  So this MAY be something new.


systemctl -l status auditd

Shows

● auditd.service - Security Auditing Service
   Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor prese
t: enabled)
   Active: failed (Result: signal) since Wed 1969-12-31 19:03:30 EST; 48 years 7
 months ago
     Docs: man:auditd(8)
           https://github.com/linux-audit/audit-documentation
  Process: 498 ExecStart=/sbin/auditd (code=killed, signal=KILL)

Dec 31 19:00:29 onlo.htt-consult.com systemd[1]: Starting Security Auditing Serv
ice...
Dec 31 19:00:29 onlo.htt-consult.com auditd[499]: Started dispatcher: /sbin/audi
spd pid: 501
Dec 31 19:01:59 onlo.htt-consult.com systemd[1]: auditd.service start operation
timed out. Terminating.
Dec 31 19:03:30 onlo.htt-consult.com systemd[1]: auditd.service stop-final-sigte
rm timed out. Killing.
Dec 31 19:03:30 onlo.htt-consult.com systemd[1]: auditd.service: control process
 exited, code=killed status=9
Dec 31 19:03:30 onlo.htt-consult.com systemd[1]: Failed to start Security Auditi
ng Service.
Dec 31 19:03:30 onlo.htt-consult.com systemd[1]: Unit auditd.service entered fai
led state.
Dec 31 19:03:30 onlo.htt-consult.com systemd[1]: auditd.service failed.

So what may be going on?

My web server, medon.htt-consult.com is practically identical and is not exhibiting this behavior.

Dec 31 19:00:30 medon auditd[499]: Started dispatcher: /sbin/audispd pid: 501
Dec 31 19:00:30 medon auditd[499]: Init complete, auditd 2.8.1 listening for events (startup state enable)


_______________________________________________
Arm-dev mailing list
Arm-dev@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev



--
Kv,
Kristján Valur Jónsson, RVX


_______________________________________________
Arm-dev mailing list
Arm-dev@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev