sssd and tmpfs

After my previous efforts to migrate to sssd, it was discovered after a reboot that sssd and a tmpfs /var/log did not play well together.  sssd has a couple of minor faults:

• If the default /var/log/sssd directory does not exist, sssd will not start
• It does not create the default /var/log/sssd directory if one does not exist first.
• You cannot change the default log directory location (without recompiling the binary, and those of us with packaged based distributions don’t want to be doing that custom step if not necessary)

Searching the web, there are a number of discussions surrounding this very issue, with the majority of them dying off with responses like “Why would you want to run tmpfs for /var/log?” “What would be the benefit?” “Seems like this isn’t a good idea”, and other useless responses.  I say useless because those types of responses are far from helpful, distract from the original question/problem, and don’t address the problem at hand that the individual is asking about.

Systemd installations (such as RHEL7 and the current Fedora tree) use the file /usr/lib/systemd/system/sssd.service as part of the sssd rpm.  Sure, you can try modifying that file, but “Type = forking” only allows for a single command in “ExecStart”.  You can go down the path of tinkering with it, writing another systemd script to create the directory structure for you, but, as I found out, that would be re-inventing the wheel.

Thankfully, I found one reference elsewhere to tmpfiles.d which is part of the systemd.  It plugs the gap where programs don’t or can’t build the directory structure you require.  Simply create the file /etc/tmpfiles.d/sssd.conf with the following contents:

# sssd needs a directory in /var/log/sssd to store its log files
d /var/log/sssd 0755 root root

The tmpfiles process is kicked off at the systemd “sysinit” level, which happens after the filesystems are mounted but before services are started.  So, you are all set.

You might ask: Why run /var/log on tmpfs?

I happen to run a number of mythtv frontend systems that are not much more than dummy clients, all of which have ssd internal drives (to limit the power usage at the TV).  I’ve done some basic optimizations to preserve the life of the SSD while still retaining debugging functionality (it is mythtv after all, which requires a lot of TLC).  Having /var/log contents can be very helpful in a pinch when logging on to the box, but I understand that both the logs and the machines are relatively disposable and I’m ok with losing the logs after a reboot.