/tmp 100% full; sometimes reflected in syslog with: Can't write to temporary file: No space left on device

  • Hi,


    This morning I got this message in syslog (since lost):

    anacron[14203]: Can't write to temporary file: No space left on device


    I ran df . -h and got:


    Is there something I can do to expand the size of /tmp?


    My understanding (shaky) is that /tmp is actually mapped to RAM on Debian. I currently have 4 GB RAM. I understand I could put in a cron job to periodically clear /tmp, but that's probably not safe for running processes. I verified /tmp is cleared on reboot.


    Thanks!

    Mark M.

  • markmarz

    Hat den Titel des Themas von „/tmp 100% full; sometimes reflected in syslog with: Can't write to temporary file: No space left on deviceNo space left on device“ zu „/tmp 100% full; sometimes reflected in syslog with: Can't write to temporary file: No space left on device“ geändert.
  • You can increase the size of tmpfs by adding a size= option in fstab. But the problem is you are already thin on RAM and increasing tmpfs will cut into your RAM even further than it does now.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


  • Thank you! I will get some more RAM. After I do that, will it still be necessary to increase the size of tmpfs or will it detect the new RAM automatically? My guess is the latter since there is no size specified in fstab now.


    One more followup, please: since I'm filling up 4 GB rapidly, I expect that I'll fill up (say) 8 GB almost as quickly. Does it make sense to (somehow) point /tmp to a fast NVMe drive with plenty of capacity to avoid further problems? If it does, a hint how would be appreciated.


    Thanks again!

    • Offizieller Beitrag

    Default settings for tmpfs is to use up to half of RAM. So I think it will be detected OK.


    It is certainly possible to use some disk partition for tmp. However it will be slower.


    You may want to figure out what it is that is using up /tmp. Simply having a look inside /tmp, possibly as root, might give some clues. Sometimes software that crash can use up /tmp without ever freeing it. Updating or fixing the software so it doesn't crash can help. Or simply reboot to clear tmpfs.

    Be smart - be lazy. Clone your rootfs.
    OMV 5: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

  • Thank you! I had the same idea and found that ALL of the 1.8GB in /tmp was used by Plex! That was a shock.


    And it so happens that there's an active discussion right now between customer support and engineers in the Plex forum about what broke /tmp usage and how to fix it. A big part of the discussion is how users are supposed to designate where Plex puts his temporary files, since some of the long prescribed ways in fact don't work!


    But I found one way that did work, so I'm using it for now. Just putting the information here in case someone finds it useful:


    Add following to override.conf in /etc/systemd/system/plexmediaserver.service.d:

    [Service]

    Environment="TMPDIR=/srv/dev-disk-by-label-data1/plex_media_server_tmpdir"


    Oh, and just to be ultra ultra clear, the dir after TMPDIR= is wherever you want your Plex temp dir to be. This is just an example.


    I think I'll go ahead and double my RAM to 8 GB anyway. Just for jollies and it's cheap.

  • Add following to override.conf in /etc/systemd/system/plexmediaserver.service.d:

    [Service]

    Environment="TMPDIR=/srv/dev-disk-by-label-data1/plex_media_server_tmpdir"

    Unfortunately this can't be done AFAIK when running Plex in a docker unless that variable is supported via an entry in the Environment table of the container. I have no knowledge if the docker supports it or not. If it does it isn't documented.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


  • Right, I know nothing about dockers so this is only applicable to a plug-in or direct Debian Plex install.


    OTOH I'm just using something I picked up from the back and forth in the Plex forum. I imagine once they have a fix it'll be migrated to the official Plex docker.

  • I imagine once they have a fix it'll be migrated to the official Plex docker.

    That wouldn't be necessary as the docker contains or downloads the package directly from Plex.

    --
    Google is your friend and Bob's your uncle!


    A backup strategy is worthless unless you have a verified to work by testing restore strategy.


    OMV AMD64 7.x on headless Chenbro NR12000 1U Intel Xeon CPU E3-1230 V2 @ 3.30GHz 32GB ECC RAM.


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!