what is the run directory?
Posted by The_How_To_Linux@reddit | linuxadmin | View on Reddit | 31 comments
quick question,
what is the run directory? what does it do? why does it exist?
when i put this into google i get
" This is a directory that stores volatile runtime data since the system was started."
what is volatile runtime data?
why would you need to store volatile run time data?
thank you
toikpi@reddit
See https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
Ormek_II@reddit
This is the only true answer. I wonder why others guess and refer to derived sources.
Kkremitzki@reddit
Other people have said the answer, but let me tell you how to find the answer. This is part of the Filesystem Hierarchy Standard. You can read about it on your system with
man hier. More info is available at:https://manpages.debian.org/bookworm/manpages/hier.7.en.html
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
jwatsone@reddit
I wonder why they use that undescriptive name "hier" for the man page entry. There are tons of better options that could make it easy to find and remember.
dodexahedron@reddit
Excellent comment.
This is a set of concepts that I feel like most people only really learn through experience or observation, and often in an incorrect or at least incomplete way.
But it's a pretty simple system, and understanding it and relevant deviations in your OS/distro* is a really useful baseline for understanding how a LOT of things work and makes finding things a lot easier, so long as your system, applications, and the configuration of those applications actually adhere to it.
* A suuuper common one is nobody consistently uses /opt and tends to dump everything in /bin or /sbin. Same goes for /srv - both apache and nginx default to /var/www, but /srv is probably a more appropriate root for that stuff, according to FHS.
paulstelian97@reddit
/usr/local/{bin,lib}. Very common.
dodexahedron@reddit
Yes. Since FHS follows actual practice (it's revised after the fact), it's strange to me that opt and srv are still there or at least not heavily annotated as optional or atypical, honestly. Because actual usage is heavily skewed toward srv data being somewhere under var, like var/lib, and applications being in either /usr/bin or /usr/local/bin. /opt is so rare I'm usually taken a bit off-guard by an application that gets dumped in there by default. And then some mis-use it as a config directory while putting their binaries in /usr/bin. đŸ˜‘
And plenty of application packages out there violate the "no binaries in /etc" thing, though most of them not technically, by putting executable scripts in there, which, to me, is the actual intent of saying "no binaries." Just because /usr/bin/python is executing it doesn't make it not a program.
MrElendig@reddit
Note: these days this is generallymore accurate https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html
Kkremitzki@reddit
Very nice resource, thank you.
deeseearr@reddit
It's like /tmp, but for things that absolutely cannot survive the next reboot.
One common use for /run is to hold pid files which tell you if a process is running and what its ID is.
If you stored those in /tmp or /var/tmp then they might still be there when you rebooted, meaning that any scripts relying in them could misbehave. /run is guaranteed by the FHS to only hold data created since the last boot so thats safer.
The_How_To_Linux@reddit (OP)
how is it "safer"?
why would a file that has all it's information wiped everytime the system reboots be considered safer?
what use would that be?
deeseearr@reddit
Okay, let's expand on that example a bit.
Suppose that you're running an application server. Let's call it "KManager", just so that it has a name. In order to stop or restart the service, you need to signal the first process, but each time you start it is spawns a half a dozen other processes with the same name and it's possible to run several different instances of it at the same time using different configuration, so looking at "ps" output is going to show you a lot of different processes all called KManager.
The way around this mess is to use PID files. These would go in /run/kmanager/instance-name/kmanager-instance-name.pid, where there can be several different "instance-name"s.
If these files were stored in /var/tmp, for example, then when the system rebooted they would still be there. Even if they were in /tmp they might still be around. If that happened then the process ID in kmanager-instance-name.pid could refer to a different process entirely, meaning that any attempt to signal or restart it could shut down the wrong process.
Other uses for /run include sockets, which would no longer be connected to anything after rebooting, or lock files, which indicate that a resource is being used right now and anyone else who needs it will have to wait. Trying to write to a discarded socket or waiting for a lockfile to be released because the process which created it doesn't exist would also be bad.
Knowing that /run is guaranteed to be cleared out at every boot means that you can trust that any files found there were created by the current system, and not a previous one.
Another useful thing about /run is that it can be created as a tmpfs very early in the boot process, while the "/" directory is still read-only and other filesystems may not have even been mounted yet. Previously having a reliable, writable place to keep state information required complicated tricks with linking to /lib/init/rw/, shadow mounting directories over top of others, or just stuffing things in /dev which didn't belong there because it was the only place available. Adding /run standardizes all of this in a way which makes sense.
To learn more about how filesystems are laid out, and why, you could go straight to the FHS.
The_How_To_Linux@reddit (OP)
ok so basically if i'm understanding this right, is that there are certain processes that are created EVERYTIME a system boots up, that need to be deleted and wiped every time when the system shuts down
if those processes aren't wiped, then the next system will try to make those same processes again but they will be waiting in line for resources from the processes of the previous operating system that aren't doing anything?
am i understanding that right?
deeseearr@reddit
Processes are always removed when the system shuts down. There's no way around that, they can't continue.
What we're talking about are the temporary files which those processes create, such as "I have started, and am using PID 4156!" or "You can send messages to me here!", which will stop being valid after the next reboot. Process 4156 will no longer be running, the communication socket will no longer be connected, and so on. If you can be guaranteed that all of these files were created after the last boot, then you can know that things like PID files will always be correct unless the process has crashed unexpectedly.
For an analogy, suppose you open up your phone and see a message from a friend saying "I'm at the library. Can you meet me there?" So you go, don't find them, and ask where they are. It turns out that the message was from two days ago and they had left long ago. Maybe you need to check your phone more often, or may be your messages just aren't arriving in time.
Messages stored in /run are the same kind of thing. If they're correct and timely, they're very useful. If they're not, then they're useless or worse.
serverhorror@reddit
Imagine you need the process ID of something in a file.
If /tmp doesn't get cleared for some reason that's bad. So you use /run which is a filesystem that does not have backing by storage.
DogMeAsWellDaddy@reddit
Volatile data is data that’s temporary and/or subject to change or loss. Data in /tmp and /var/tmp may be preserve on boot. Though/tmp is more likely to be flushed. /run contains things like PIDs, sockets, lock files. The content in /run is generated during boot.
The_How_To_Linux@reddit (OP)
how is this useful?
how is it useful to have a specific folder you can always rely on to have the data wiped after every reboot?
DogMeAsWellDaddy@reddit
How is home useful?
The_How_To_Linux@reddit (OP)
so lock and socket files are shit?
DogMeAsWellDaddy@reddit
You completely missed the point…
The_How_To_Linux@reddit (OP)
aw :(
Aaron-PCMC@reddit
This is perfect. Thank you for this
dhsjabsbsjkans@reddit
OMG. Why can't you just accept the answers. Every time someone answers, you ask another question. But why? Some things you just have to accept. There is no need to dig deeper.
Aaron-PCMC@reddit
His account has negative 100 karma, if that is any indication of his typical interactions on this website.
dhsjabsbsjkans@reddit
Dude. I saw his profile. It was unreal. Question after question. He could probably get answers from generative AI.
The_How_To_Linux@reddit (OP)
i could, but the answers are always shit.
dhsjabsbsjkans@reddit
Did the AI ask you to stop asking so many questions? Then it pointed you to Google?
The_How_To_Linux@reddit (OP)
https://www.youtube.com/watch?v=oqwzuiSy9y0&ab_channel=Movieclips
edthesmokebeard@reddit
I think its a systemd thing. Because putting stuff in /var wasn't ephemeral enough somehow.
QuickBASIC@reddit
It's a tmpfs that's loaded very early in the boot process. Things like systemd or udev use it to write runtime information. Volatile because it's tmpfs and therefore kept in volatile memory i.e. RAM.
emprahsFury@reddit
It's not necessarily a tmpfs, and when it is: it isn't volatile because it's tmpfs; it's tmpfs because the data is volatile.