6

Ran into an issue today where Apache would not load because /var/run/httpd was missing. After much hunting to find that cause of the error I was getting ([Tue Jul 25 00:06:31.574386 2017] [auth_digest:error] [pid 6179] (2)No such file or directory: AH01760: failed to initialize shm - all nonce-count checking, one-time nonces, and MD5-sess algorithm disabled).

Then I saw that MariaDB was missing its /var/run/mysql directory, and PostgreSQL was missing its directory.

What would cause those to not be made on system start-up / saved between reboots?

I would not expect to need to modify init scripts as suggested in this question.

Edit: outputs of ls -dl /var/run & ls -dl /run

lrwxrwxrwx. 1 root root 6 Dec 15  2015 /var/run -> ../run
drwxr-xr-x 25 root root 800 Jul 26 03:40 /run
3
  • something does not add up. was your var filled up and you took care of it? are you low in memory? is run or /var/run in disk or ram? Jul 25 '17 at 6:47
  • add also the output of free -m please Jul 25 '17 at 6:48
  • @bbb31 - tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
    – warren
    Jul 26 '17 at 14:16
3

{/var,}/run is vaporized by systemd on boot. It's a wonderful and entirely unexpected surprise with such low value.

If you want to ensure a directory exists after boot, you'll have to hook something in with the tmpfiles section of systemd.

/usr/lib/tmpfiles.d/httpd.conf
::::::::::::::
d /run/httpd   710 root apache
d /run/httpd/htcacheclean   700 apache apache

/usr/lib/tmpfiles.d/mariadb.conf
::::::::::::::
d /var/run/mariadb 0755 mysql mysql -

And, if your tmpfiles entries are missing, I'm betting you hand-roll your own packages (and tune, and test, and promote, for every.single.release). As long as we agree it's usually a bad idea for anything with scale or an SLA, that's cool though.

1

These config files reside /usr/lib/tmpfiles.d and /etc/tmpfiles.d/.

I needed to unmask and enable the systemd-tmpfiles-setup.service in order to have /run automatically setup at boot: systemctl unmask systemd-tmpfiles-setup.service systemctl enable systemd-tmpfiles-setup.service

0

Not a fix - but a fix.

After trawling through other SE network sites, forums, newsgroups, and the like, I wondered if it might be related to mount order for local and remote file systems (there are a pair of CIFS shares mounted on this server, which each have subdirectories bind mounted elsewhere).

I pushed the CIFS shares higher in /etc/fstab, and moved all bind mounts to the bottom.

Then I rebooted.

Now /run aka /var/run is working as expected.

I don't know that editing /etc/fstab mattered - but it's the only substantive change made that I know of.

0

/var/run is considered to be a volatile and temporary directory.

tmpfiles.d is for the configuration for creation, deletion and cleaning of volatile and temporary files, which includes directories in /var/run

Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d. Files in /etc/tmpfiles.d are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages.
source: https://www.systutorials.com/docs/linux/man/5-tmpfiles.d/

You can cat existing configs in /usr/lib/tmpfiles.d and ls -l /var/run permissions to help determine appropriate permissions.

create a new file [name] or httpd in /etc/tmpfiles.d; example based on /usr/lib/tmpfiles.d/screen

httpd

# httpd  needs directory in /run  
d /run/httpd 0775 root apache

generic

# [name] needs directory in /run  
d /run/[name] [perms] [user] [group]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.