The Filesystem Hierarchy Standard (FHS) provides clear but sometimes overlapping guidelines for storing variable data. Let's examine the key differences:
# FHS 2.3 relevant sections:
/var/lib - Host-specific state data (persistent across reboots)
/var/opt - Variable data for packages in /opt
When choosing between these locations for your package's working directory, consider these technical factors:
- Installation method: Did the package come through system package manager or manual /opt installation?
- Data nature: Is this pure state data or mixed with temporary/cache files?
- Portability: Will this data need to move with the package if relocated?
For a package named "exampleapp" installed in /opt/exampleapp, here's how you might implement both approaches:
// Option 1: Using /var/opt
working_dir = Path("/var/opt/exampleapp/data");
// Option 2: Using /var/lib
working_dir = Path("/var/lib/exampleapp");
In systemd service files, you would configure these paths differently:
[Service]
# For /var/opt approach
WorkingDirectory=/var/opt/exampleapp
# For /var/lib approach
StateDirectory=exampleapp
For packages installed in /usr/local, the equivalent would be:
working_dir = Path("/var/local/package_name");
When dealing with containerized applications, the decision changes:
# In Docker, you might bind mount either location
docker run -v /var/opt/exampleapp:/app/data exampleapp
# OR
docker run -v /var/lib/exampleapp:/app/data exampleapp
- Prefer /var/opt for /opt packages that maintain their own data structures
- Use /var/lib when the data represents system-wide state information
- For hybrid cases, consider splitting data types between locations
When dealing with third-party packages installed in /opt
or /usr/local
, the Filesystem Hierarchy Standard (FHS) presents two seemingly competing directives:
# FHS 2.3 Relevant Sections:
/var/lib - Variable state information (host-specific, persistent)
/var/opt - Variable data for packages in /opt
The key distinction lies in the nature of the data rather than just its origin:
- /var/lib: For stateful data that's critical to application operation (e.g., databases, registry files)
- /var/opt: For auxiliary variable data (e.g., logs, caches, temporary working files)
Consider a monitoring tool installed in /opt/monitor
:
# Correct FHS-compliant structure:
/opt/monitor/ # Main application
/var/opt/monitor/logs/ # Application logs
/var/lib/monitor/ # Configuration state and registry
Use this logic when deciding storage location:
if (data_is_critical_state):
use /var/lib/$package
elif (package_in_opt):
use /var/opt/$package
else:
use /var/lib/$package
In your package's post-install script:
#!/bin/bash
# For state data
mkdir -p /var/lib/${PKG_NAME}/registry
chown ${DAEMON_USER}:${DAEMON_GROUP} /var/lib/${PKG_NAME}
# For operational data
mkdir -p /var/opt/${PKG_NAME}/cache
chmod 755 /var/opt/${PKG_NAME}
For locally compiled software, FHS recommends:
/usr/local/var/lib # Mirroring /var/lib convention
/usr/local/var/log # Instead of /var/log/local