/run
state since the last boot/run holds what is true only while the system is up. Which process id a service has, the socket other programs use to reach it, who is logged in — facts about this boot, and no other. It lives in memory, and it starts empty every time the machine does.
Written at boot, gone at shutdown.
Why it exists
Every directory at the top of the tree is there for a reason. This is the problem /run solves.
Services start writing state very early in boot, before /var may be mounted. A directory in memory is always available.
A PID file left over from before a crash would name a process that no longer exists. Because /run is cleared at every boot, that cannot happen.
What you find inside
Not everything, but the entries worth recognising. Each is marked as a directory, a file, a link or a device.
- sshd.pidfileThe process id of the running SSH server.
- systemddirectorysystemd’s own runtime state.
- user/1000directoryPer-user runtime files, in a directory named by user id.
- docker.sockfileThe socket the docker command uses to reach the Docker service.
- lockdirectoryLock files that stop two programs using one resource at once.
At the terminal
Four commands that show what this directory is doing on a real machine.
df -h /runShow that /run is a tmpfs — in memory, not on a disk.
cat /run/sshd.pidRead the process id of a running service.
ls -l /var/runShow that the old name is now a link to /run.
ls /run/user/$(id -u)List your own runtime directory.
Handle with care
What goes wrong here, and what someone securing or attacking the machine looks at.
Whatever is placed in /run is gone after a reboot. It is for programs’ working state, not for files you want to keep.
Anyone who can write to docker.sock can control Docker, and through it the whole machine. Check who is allowed to reach each socket.