You spend half an hour troubleshooting why your custom service fails to write to a socket in /run, only to find the directory missing or wiped clean. Most docs tell you to create the directory in your ExecStartPre, but that is a race condition waiting to happen. The real culprit is often systemd-tmpfiles, which runs before your service and has its own ideas about what should exist in your runtime paths.

Why systemd-tmpfiles gets in your way

When you put a path in your unit file, systemd tries to be helpful by managing it. If you have a global configuration in /usr/lib/tmpfiles.d/ that matches your directory, it will wipe it during the early boot sequence. I have seen this silently destroy application state that needed to persist across service restarts, simply because the cleanup pattern was too aggressive.

systemd-tmpfiles --create --exclude-prefix=/run/your-app-path

• Avoid using /tmp for anything that needs to survive a service restart
• Use RuntimeDirectory in your service file to let systemd handle the life cycle safely
• Check /etc/tmpfiles.d/ for custom configs that might conflict with your own unit

If you are struggling with missing directories, stop using mkdir inside shell scripts. Add RuntimeDirectory=your-app-name to your service unit instead. This keeps the logic within the init system itself. It will handle the ownership and permissions correctly before your main process forks, which beats chasing down why a directory disappeared every time you cycle the daemon.