15

I mount /tmp on tmpfs using:

sudo systemctl enable tmp.mount
sudo systemctl start tmp.mount

But this way /tmp takes up all the free RAM:

$ df -h /tmp
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G   12K  3.9G   1% /tmp
$

How do I tell systemd tmp.mount to use only 1G? I know I can alternatively not use systemd and manually add an entry to /etc/fstab and specify the size there. But I don't want to do that. I want to use systemd backed tmpfs.

Marco
  • 893
GMaster
  • 6,322

1 Answers1

17

The systemd way of overriding tmp.mount, or extending it, is to add a local override in /etc/systemd/system. You can either copy the existing tmp.mount (from /lib/systemd/system or /usr/share/systemd probably) and edit the copy, or better yet, add configuration snippets to only change the mount options, by running

sudo systemctl edit tmp.mount

and entering

[Mount]
Options=mode=1777,strictatime,nosuid,nodev,size=1G

in the editor which opens. This will

  • create a directory called /etc/systemd/system/tmp.mount.d
  • inside that directory, add a file called override.conf containing the text above.

Note that systemd.mount still says that

In general, configuring mount points through /etc/fstab is the preferred approach.

so you may just want to do that, i.e. edit /etc/fstab to add the size=... option on the /tmp line (adding it if necessary):

tmpfs /tmp tmpfs mode=1777,strictatime,nosuid,nodev,size=1G 0 0

In fact, this is the recommended approach to change mount options for any of systemd’s “API file systems”:

Even though normally none of these API file systems are listed in /etc/fstab they may be added there. If so, any options specified therein will be applied to that specific API file system. Hence: to alter the mount options or other parameters of these file systems, simply add them to /etc/fstab with the appropriate settings and you are done. Using this technique it is possible to change the source, type of a file system in addition to simply changing mount options. That is useful to turn /tmp to a true file system backed by a physical disk.

API file systems include the following: /sys, /proc, /dev, /run, /tmp, /sys/fs/cgroup, /sys/kernel/security, /sys/kernel/debug, /sys/kernel/config, /sys/fs/selinux, /dev/shm, /dev/pts, /proc/sys/fs/binfmt_misc, /dev/mqueue, /dev/hugepages, /sys/fs/fuse/connections, /sys/firmware/efi/efivars. systemd ensures they are mounted even if they are not specified in /etc/fstab or a mount unit.

Be careful when sizing tmpfs file systems: they will end up competing with whatever else in your system needs memory (including swap), and can result in memory exhaustion when you don’t expect it; at worst this can result in deadlocks.

Stephen Kitt
  • 434,908
  • 1
    Based on https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html you can use symbolic values for size using suffixes. Example: size=1G. Side story: I just discovered that if you don't specify anything the kernel takes... 50% of the RAM for this tmpfs, which is probably nowadays crazy. This was killing my 32GB laptop... – Patrick Mevzek Jul 15 '22 at 15:16
  • 1
    Yes, the default of 50% can be surprising; but it’s strange that that would kill your laptop, because a tmpfs only allocates memory as needed to store the data (up to the configured size). – Stephen Kitt Jul 15 '22 at 15:26
  • 2
    As the page says: "If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory." Heavy applications over consuming memory were exactly triggering this and I now resized my /tmp to be far smaller and I hope not to have deadlocks anymore. – Patrick Mevzek Jul 15 '22 at 15:47
  • 1
    Unfortunately the documentation is very old and not necessarily accurate; I think there’s a bit more to it than “set size too large → deadlock”. I have several tmpfs mounts using the default settings, and as long as they don’t fill up too much my system works fine (including swapping out the tmpfs contents as necessary). It’s even possible to mount a tmpfs with a size far larger than installed memory or even RAM+swap, without adverse effects (as long as it’s not too full of course). Of course limiting tmpfs size is a good idea, I’m not saying the contrary. – Stephen Kitt Jul 15 '22 at 16:42
  • I guess all is in the "and as long as they don’t fill up too much" and "ncluding swapping out the tmpfs contents as necessary" (I didn't have real swap enabled), hence many variations in behavior possible. I just reduced my /tmp (from 16 to 1G) and I hope it resolves my mad deadlocks/OOMs, I will see... I can't vouch that it is the real root cause (even if it is clearly memory related) but at least I thought pointing out that bit in documentation can help others... of course if it is still current, that I don't know. – Patrick Mevzek Jul 15 '22 at 16:56
  • 1
    Good point about warning readers, I’ve added a paragraph about sizing. – Stephen Kitt Jul 15 '22 at 17:00
  • For Debian/Ubuntu you may need to make tmp.mount available first with sudo ln -s /usr/share/systemd/tmp.mount /etc/systemd/system/. Then when overriding the size via sudo systemctl edit tmp.mount, use the existing Options line as a base in case it contains additional mount options. – Walf Oct 25 '23 at 02:18