CentOS - Sep 2015 - Cannot open: No space left on device

On Fri, Sep 11, 2015 at 3:19 PM, Dario Lesca <d.lesca at solinos.it>
wrote:
> the result.

# du -sc /* /.??* --exclude /proc|sort -n
0       /.autofsck
0       /.autorelabel
0       /misc
0       /net
0       /sys
4       /cgroup
4       /media
4       /mnt
4       /selinux
4       /srv
8       /opt
16      /home
16      /lost+found
16      /tmp
112     /root
188     /dev
7956    /bin
14624   /sbin
27088   /lib64
31636   /etc
78796   /boot
284672  /lib
1882548 /usr
14422860        /var
16750556        total

lsblk /dev/sda
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0   30G  0 disk
??sda1                         8:1    0  500M  0 part /boot
??sda2                         8:2    0 29.5G  0 part
  ??vg_server-lv_root (dm-0) 253:0    0 26.5G  0 lvm  /
  ??vg_server-lv_swap (dm-1) 253:1    0    3G  0 lvm  [SWAP]

did you (or someone else with root access) possibly delete a very large
file in /var that may still have been in use?    it's very annoying but
if you do a rm on a large file under /var that is still open by some
process for writing, it won't actually clear the space.   you can
overcome that by just truncating the file instead of doing an rm (e.g.
either > /var/log/bigfile or cp /dev/null /var/log/bigfile).   the only
way I know to fix the problem once you're having it is to force the
process to close/reopen the file... either by killing & restarting or
getting the process to do it if it's got that designed in.   in practice
I've often found it much easier to reboot a machine to fix such a
problem condition.

-- 
public gpg key id: AE60F64C

On Fri, Sep 11, 2015 at 3:52 PM, zep <zgreenfelder at gmail.com> wrote:
> did you (or someone else with root access) possibly delete a very large
> file in /var that may still have been in use?    it's very annoying but
> if you do a rm on a large file under /var that is still open by some
> process for writing, it won't actually clear the space.   you can
> overcome that by just truncating the file instead of doing an rm (e.g.
> either > /var/log/bigfile or cp /dev/null /var/log/bigfile).   the only
> way I know to fix the problem once you're having it is to force the
> process to close/reopen the file... either by killing & restarting or
> getting the process to do it if it's got that designed in.   in
practice
> I've often found it much easier to reboot a machine to fix such a
> problem condition.
>
In fact, that's exactly what I did. I have tried to open that 14G .tar.gz
file from mc and it crashes several times so I delete the temporary files
from /tmp and also from /home where originally I copied. I've rebooted the
VM and now the output of df -h looks better:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_server-lv_root
                       26G   16G  8.7G  65% /
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/sda1             477M   80M  373M  18% /boot