1. Resize /run
mountpoints
According to the
tmpfs
documentation
, "tmpfs
has three mount options for sizing" where
size is
The limit of allocated bytes for this tmpfs
instance. The default is half of your physical RAM
without swap. If you oversize your tmpfs instances
the machine will deadlock since the OOM handler will
not be able to free that memory.
That is to say, it can be set to an arbitrarily
large size, but **make sure that there is enough RAM
or swap space (or combination thereof), so adjust
the latter if needed (see 4. below).
In my case, I set it to 15 GB for starters, and it
was enough.
sudo mount -o remount,size=15G,noatime /run/user/1000
2. Adjust swap space
2.1 Temporarily
Used this Askubuntu answer in the following way:
Check current swap:
$ free -th
total used free shared buff/cache available
Mem: 7.7G 4.6G 253M 985M 2.8G 1.8G
Swap: 975M 0B 975M
Total: 8.6G 4.6G 1.2G
$ sudo swapon -s
Filename Type Size Used Priority
/dev/dm-2 partition 999420 3840 -2
Setting up the swap file, and turning it on:
$ sudo touch /temp_swap_15G.img
$ sudo fallocate -l 15G /temp_swap_15G.img
$ sudo mkswap /temp_swap_15G.img
# `-p` is the priority; the default is -2 and anything
# higher will be used first
$ sudo swapon -p 27 /temp_swap_15G.img
Checking the results:
$ sudo swapon -s
Filename Type Size Used Priority
/dev/dm-2 partition 999420 4352 -2
/temp_swap_15G.img file 15728636 0 27
2.2 Permanently
StackExchange answers (snapshots available on archive.org):
This is a troubleshooting one for the LVM one:
Note: On NixOS, instead of the steps above, the process would have been simply
- to edit the
services.logind.extraConfig
attribute in /etc/nixos/configuration.nix
:
services.logind.extraConfig = ''
RuntimeDirectorySize=12G
HandleLidSwitchDocked=ignore
'';
- Rebuild configuration (e.g., with
sudo nixos-rebuild switch
).
More info:
What is /run
?
This
is the authoriative answer, but
this Quora answer
sums it up:
/run
is the "early bird" equivalent to /var/run
,
in that it's meant for system daemons that start
very early on (e.g. systemd
and udev
) to
store temporary runtime files like PID files and
communication socket endpoints, while /var/run
would be used by late-starting daemons (e.g. sshd
and Apache).
Traditional /var/run
was an actual directory on
disk, which meant the underlying filesystem may not
have been mounted at the point systemd
et al
needed to write stuff into it. Making /run
a
tmpfs (i.e. RAM-based) filesystem neatly solved this
problem and eliminated the need to clean it up on
the next boot.
Of course, having two runtime scratch directories
struck many as being a bit much, so in many modern
Linux distros, /var/run
is just a symlink to
/run
.
What is tmpfs
?
kernel.org/doc/Documentation/filesystems/tmpfs.txt:
Everything in tmpfs is temporary in the sense that
no files will be created on your hard drive. If you
unmount a tmpfs instance, everything stored therein
is lost.
tmpfs puts everything into the kernel internal
caches and grows and shrinks to accommodate the
files it contains and is able to swap unneeded pages
out to swap space. It has maximum size limits which
can be adjusted on the fly via mount -o remount ...
Also, "tmpfs lives completely in the page cache and
on swap".
No space left on device
on/run
, you have a much more fundamental problem that needs resolution.