openSUSE 12.1 erases /var/run at each reboot, so shibd fails to start

Description

Problem: shibd tries to create files and sockets in /var/run/shibboleth. This directory is created once when the RPM is installed, but in openSUSE Linux 12.1 /var/run (as well as /var/lock) is now mounted on tmpfs, and therefore emptied automatically at each reboot.

How to reproduce:

  • Install shibboleth-2.4.3-3.1.i586.rpm

  • "/etc/init.d/shibd start" works fine

  • reboot

  • "/etc/init.d/shibd start" fails with

2011-12-19 17:58:20 ERROR Shibboleth.Listener : socket call resulted in error (2): no message
2011-12-19 17:58:20 CRIT Shibboleth.Listener : failed to bind to socket.

in /var/log/shibboleth/shibd.log.

Suggested fix/workaround: Add the line

[ -d /var/run/shibboleth ] || mkdir /var/run/shibboleth

to /etc/init.d/shibd, or equivalent, to recreate (as root) that directory each
time before starting shibd, if necessary.

See also: http://blog.stastnarodina.com/honza-en/spot/shibboleth-ubuntu/

Related considerations:

  • According to

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

the directory /var/run is only meant for information related to
currently running processes, which by definition can be discarded
at each reboot, such as pids and sockets. For more long-term state,
please consider using /var/cache or /var/lib instead.

  • The above error message in /var/log/shibboleth/shibd.log could be
    improved by actually stating what went wrong in terms of file path
    and errno (here: ENOTDIR), e.g. "bind() cannot create
    /var/run/shibboleth/shibd.sock: not a directory"

Environment

openSUSE Linux 12.1

Activity

Scott Cantor March 1, 2012 at 9:01 PM

http://svn.shibboleth.net/view/cpp-sp?rev=3588&view=rev

Main patch to fix makefiles, specfile, and init scripts to handle /var/cache directory and recreate rundir at startup.

Windows installer still needs to be updated.

Scott Cantor January 21, 2012 at 11:21 PM

Include re-direction of cache/backup files along with fixing the creation of the run directory.

Scott Cantor December 20, 2011 at 6:50 PM

Thanks. Regarding the error message, the "no message" in the log is because that's what the OS gave me. Since errno appears to be set (2), I assume the bug is in the strerror call, but I can't see where.

Fixed

Assignee

Reporter

Original estimate

Components

Fix versions

Affects versions

Created December 20, 2011 at 6:40 PM
Updated August 7, 2012 at 1:05 AM
Resolved June 4, 2012 at 6:58 PM