solera-restartauditd-shm Daemons were killed after upgradation
search cancel

solera-restartauditd-shm Daemons were killed after upgradation

book

Article ID: 241005

calendar_today

Updated On:

Products

Security Analytics

Issue/Introduction

After upgrading from version 8.0.4 to version 8.1.3.
Below daemons were died.


solera-restartauditd-shm-postgress.service
solera-restartauditd-shm-extractor.service
solera-restartauditd-shm-meta.service

Questions below.
1. What does each of the three daemons do?
2. Even if 3 daemons die, is there no big problem?
3. What are your recommendations?

 

Environment

Security Analytics : 8.1.3-54751

 

Resolution

This is a known issue that was fixed in 8.2. During startup, there are several times when the “auditd” services should be restarted. That is the intent of those services. There was a race condition between those services that sometimes causes them to fail. It is safe to restart these services manually to clear the errors.


systemctl restart solera-restartauditd-shm-postgress
systemctl restart solera-restartauditd-shm-extractor
systemctl restart solera-restartauditd-shm-meta

These daemons are only intended to be run once at startup. They are “one-shot” services. They basically monitor directories in /dev/shm and when they see they are created they restart auditd. If the audit isn’t restarted then it doesn’t monitor the directories correctly. But, it doesn’t impact the overall functionality of the system. There’s just the potential that changes to files wouldn’t be logged correctly in the audit trail.

But, if you restart the services one by one on the console, you should succeed after boot and each one will restart auditd. The problem was you could try to run at about the same time and would fail because the audit was in the middle of restarting when they tried to restart it again.

So, the quick fix is to restart the services. The real fix is to upgrade to 8.2.5 where it is fixed.

No reboot is required, after restarting the services in 8.1.3.