[SOLVED] Strange NO Room left message when I have plenty of room on HDD

BW-userx · 12-14-2015, 07:05 AM

This is an error message that just showed up today when i opened up one of my terminals that screenfetch is now giving me that to me makes no sense at all because I have plenty of room on all of my drives.

does any one got an idea why I'd be getting this and now to fix it?

just a sniplet of error message

Code:

/usr/bin/screenfetch: line 3907: cannot create temp file for here-document: No space left on device
         -Invnvvnsi..___..=sv=.     `          
/usr/bin/screenfetch: line 3907: cannot create temp file for here-document: No space left on device
           +Invnvnvnnnnnnnnvvnn;.              
/usr/bin/screenfetch: line 3907: cannot create temp file for here-document: No space left on device
             ~|Invnvnvvnvvvnnv}+`              
/usr/bin/screenfetch: line 3907: cannot create temp file for here-document: No space left on device
                -~"|{*l}*|""~

what Linux says I have avaible on all of my drives

Code:

[userx@voided ~]$ df
Filesystem     1K-blocks      Used Available Use% Mounted on
devtmpfs         1957588         0   1957588   0% /dev
tmpfs            2007908       568   2007340   1% /dev/shm
tmpfs            2007908       820   2007088   1% /run
/dev/sda2      103081248   6808988  91012996   7% /
cgroup           2007908         0   2007908   0% /sys/fs/cgroup
/dev/sda3      857058164 503474968 310024044  62% /home
/dev/sdb1      961301832 863084988  49362420  95% /media/data
tmpfs            2007908   2007908         0 100% /tmp
/dev/sdc1      976727868 623535516 353192352  64% /run/media/userx/WD

Just in screenfetch dir - which is the same as / 7% used,

Code:

[userx@voided ~]$ df /usr/bin/screenfetch
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda2      103081248 6808988  91012996   7% /

the only thing I see at 100%

Code:

tmpfs            2007908   2007908         0 100% /tmp

this is what is inside of /tmp

Code:

ls /tmp
1000-runtime-dir  easytag-ATI98X  easytag-FN1D9X  easytag-KBGB9X  easytag-MNLO9X  easytag-SK248X  easytag-TKSN9X  geany_socket.5ef0f2fe    tmpkCC8E1412589031.key
easytag-6OGN9X    easytag-CYV28X  easytag-HX1K9X  easytag-L6CK9X  easytag-NH4B9X  easytag-SWGC9X  easytag-Y3LF9X  tmpCkvoUl412589031.cert

if I do a

Code:

rm /tmp/*

everything should be ok rignt? like I am not going to get rid of needed files and have to reinstall OS, BUT that should fix it,right?

just wanting to be sure.

TWO:

As I have only 7% usage of / (root) then why is /tmp full? can I change specs to have it hold more stuff before saying it is full? Because that is what it has to be doing.

jpollard · 12-14-2015, 08:11 AM

/tmp is using a tmpfs mount which (by default) uses one half of ram for maximum storage. It is not the root filesystem.

And "out of space" can mean one of two things: you are out of data space (which is the case you have shown) or out of inodes (df -i).

And it isn't necessary to reinstall. Since /tmp is a tmpfs, just rebooting will clean it out.

An "rm /tmp/*" will delete any ordinary files in /tmp... But that doesn't mean the data gets deallocated immediately. If the file is open by any process then the deallocation will be delayed until the last process that has the file open closes the file (either via normal operation, or when it terminates). It also will not delete any directories or hidden files there (such as .X11-unix, .X0-lock, .X1-lock...)

BW-userx · 12-14-2015, 09:00 AM

Quote:

Originally Posted by jpollard

/tmp is using a tmpfs mount which (by default) uses one half of ram for maximum storage. It is not the root filesystem.

I've never came across this before.

So it could have been just a RAM thing usage full @ 50% of my installed RAM. which just a reboot could have delt with. (looked like that easyTag was using a lot a real space- I just deleted everything easyTag after shutting that down, then had to do a reboot to get my terminal to actually show a complete ls dir listing even.

Quote:

Originally Posted by jpollard

And "out of space" can mean one of two things: you are out of data space (which is the case you have shown) or out of inodes (df -i).

And it isn't necessary to reinstall. Since /tmp is a tmpfs, just rebooting will clean it out.

An "rm /tmp/*" will delete any ordinary files in /tmp... But that doesn't mean the data gets deallocated immediately. If the file is open by any process then the deallocation will be delayed until the last process that has the file open closes the file (either via normal operation, or when it terminates). It also will not delete any directories or hidden files there (such as .X11-unix, .X0-lock, .X1-lock...)

thanks, -- rule of thumb for tmp stuff is that no matter whats in there it is usally ok or yes it's ok to delete everything within that dir when everything that has used that dir for its data is done and it just happens to leave its remnants there leaving it to the user to clean up afterwords?

JMS (just making sure)

on that re-install thing, so yeah I've played with that rm function and have removed more then necessary before on them oops didn't type that right operations... got a start over now

that's why I asked.

jpollard · 12-14-2015, 09:39 AM

About the only thing you don't usually want to delete (on a desktop at least) is the ./X* lock files and ./X11-unix.

The .X11-unix directory contains the sockets used to connect to instances of the X server, and the ./X[01...]-lock files are used to prevent accidental duplication when alternate users get logged in (created by the "switch user" option in the screen locks).

A simple reboot will recreate them though so it isn't catastrophic.

BW-userx · 12-14-2015, 12:34 PM

Quote:

Originally Posted by jpollard

A simple reboot will recreate them though so it isn't catastrophic.

thanks for the InFO