Failed to start Security Audit Service, Authorization Manager and Login Service

A power outrage caused one of our servers to shut down unexpectedly and after it had been powered up the server did not show up. The server was unreachable and apparently, the network did not bring up the interfaces.
Loading the IPMI KVM Console and rebooting the server there were three errors on the screen during the boot up of the CentOS 7:

[FAILED] Failed to start Security Audit Service.
See 'systemctl status auditd.service' for details.
....
....
[FAILED] Failed to start Authorization Manager.
See 'systemctl status polkit.service' for details.
....
....
[FAILED] Failed to start Login Service.
See 'systemctl status systemd-logind.service' for details.

And after the above last line, the system stopped loading.
The disks are clean, but there was no login service, so you cannot log in to the server through the keyboard and the monitor! There was no network as mentioned above, which meant no logging at all in the server. You might not know, but if auditd service is enabled you probably use Selinux!

STEP 1) Failed to start the three important services – Security Audit Service, Authorization Manager and Login Service.

So we ended up with unability to log in our server.

main menu

Not sure what exactly caused this problem (seems strange a perfectly working Selinux enabled CentOS 7 server to have miss-labeled files in the root only because of an unexpected shutdown), but to be able to fix the issue and bring back your server to life

you need a rescue CD/USB/DVD/PXE Server to boot from and mount the disks and relabel your root file system.

STEP 1) Boot from a rescue CD/USB/DVD/PXE Server.

In our case, we used the IPMI KVM Console and mounted a Gentoo ISO disk and then booted from it to have a bash shell in our system. Our root resides on software RAID 1, so cat the /proc/mdstat and mount your root file system somewhere (/mnt/gentoo is there by default…)

STEP 2) Booted in our rescue Gentoo CD and mount your root file system.

main menu
Rescue Gentoo CD

STEP 2) create a file “.autorelabel” in the mounting point of your root file system.

So in our case, we mounted our CentOS 7 root file system in /mnt/gentoo and you must create a file with patch “/mnt/gentoo/.autorelabel”. umount and reboot. And a few minutes later your server will be back from the dead. A quick and handful advice – edit your /etc/fstab to mount only the root file system by commenting out all other big storage mounts – of course, if it is possible. We have big storage with millions of files in /mnt/storage-01 and we put the “#” to comment out the line with it – we do not want to wait for relabeling this file system, because the problem apparently is in our root file system! If it is possible (it is highly recommended) to relabel only the root file system in such situations to be able to regain shell control over your server fast.

Bonus – booted in rescue but no logs

OK, we booted to the rescue and tried to see what was the error (with journalctl in chrooted /mnt/gentoo), which did not allow auditd, polkit and systemd-logind to fail to start, but it appeared by default the systemd logs are not persistent on the disk in CentOS 7, so when you reboot in rescue you do not have systemd logs from the last boot! As a piece of additional advice here you may consider enabling persistent systemd logs!

How to proper enable the selinux in a CentOS7 installed server

These days many dedicated servers are offered with automation installation of operating systems and it have never been so easy and fast to pay a server and to get it up in minutes! Yes, we are talking for dedicated machines not virtual servers or cloud ones, but many cloud ones are in the same situation, when the host uses full virtualization.
It is fast, you can choose from many different linux distros and the installation is unattended and happens immediately, but in most cases the selinux is disabled, because is more easy for the support, for the user, for the admin, and for the offered preinstalled software…If you do not have some strange software in most cases it is advisable to enable the selinux, because it is of great security enhancement for your server and for the software in general. It is very simple to enable selinux, but there is an additional step, which if you omit, the server will probably get unusable (probably you won’t be able even to ssh it or login). These steps are tested under CentOS7, but probably works in all other distros, which support selinux!
So here are the steps:

STEP 1) Enable selinux in configuration

Edit the configuration file in

/etc/selinux/config

SELINUX=enforcing

STEP 2) relabel the file system

When using the selinux, there are labels (extended attributes of the file system), which are additional layer of security. Every system comes with prebuild rules instructing what label is set in which file or directory, so when you enable the selinux you must relabel the entire file system (or at least the root partition, to be able to boot normally). This is done with just a line of code below:

touch /.autorelabel

STEP 3) reboot

To take effect the changes made above the server must be rebooted.

reboot

The init process will find the file from step 2 “/.autorelabel” and will initiate a proper relabel according the current selinux rules file, then the server will be rebooted automatically again, the relabel could take time and it depends on the number of files you have in your server, just keep patient.
After the second reboot (which is automatically after the relabeling)

4) Recommendations

USE SELINUX, do not disable it! In most cases it is really simple to configure it in minutes for the need of your special software and for the generic one bet it there are rules offered in the distro’s packet system.

4) Post install check

You can check if the selinux is enabled with

[root@srv ~]# getenforce 
Enforcing
[root@srv ~]#