[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /var partition seems locked or read only





Le 23.07.2014 18:38, berenger.morel@neutralite.org a écrit :
Hello.

On a distant Debian testing/unstable, it seems that the /var
partition can no longer be written: even "# touch /var/test" returns a message saying that there is no space on the drive, which is something
that "# df -h" deny:

# df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/sda3          9,1G    954M  7,7G  11% /
udev                10M       0   10M   0% /dev
tmpfs              397M    384K  396M   1% /run
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              2,7G       0  2,7G   0% /run/shm
/dev/sda2          4,4G     27M  4,4G   1% /boot
/dev/sda5           38G     22G   16G  58% /home
/dev/sda7          447M     17K  423M   1% /tmp
/dev/sda6           14G    2,7G  8,7G  24% /var

So, I am guessing that something is locking the partition, but I have
no idea about *what* could do that. I tried disabling as many daemons
that I can, so that "# service --status-all |grep '+'" returns this:

# service --status-all |grep '+'
 [ ? ]  bootmisc.sh
 [ ? ]  checkfs.sh
 [ ? ]  checkroot-bootclean.sh
 [ ? ]  hwclock.sh
 [ ? ]  ircd-irc2
 [ ? ]  killprocs
 [ ? ]  kmod
 [ ? ]  mountall-bootclean.sh
 [ ? ]  mountall.sh
 [ ? ]  mountdevsubfs.sh
 [ ? ]  mountkernfs.sh
 [ ? ]  mountnfs-bootclean.sh
 [ ? ]  mountnfs.sh
 [ ? ]  networking
 [ ? ]  rc.local
 [ + ]  rsyslog
 [ ? ]  sendsigs
 [ + ]  ssh
 [ + ]  udev
 [ ? ]  udev-finish
 [ ? ]  umountfs
 [ ? ]  umountnfs.sh
 [ ? ]  umountroot

but it changes nothing. Any idea/supposition/whatever?

Some other informations which might help:
The problem started with a network failure, which avoided aptitude to
download, and so update, some packages, and now some packages are
broken (but dpkg was not concerned by the update). If I can still
trust /var/lib/dpkg/status, it seems that the most important breakage
may come from libasan0 (Status: install reinstreq half-configured)
which is needed by libgcc-4.8-dev, itself needed by linux-headers, so
I do not think it is the source of the problem, but... maybe?

According to /etc/mtab, the var partition is mounted as rw:
"/dev/sda6 /var ext4 rw,nodev,noatime,data=ordered 0 0".

Thanks to people which have replied, it appears that the problem is the inode's exhaustion. I have identified with lot of "find </var/DIRECTORY> -name '*'" that the problem comes from the cache, and especially from apt-cacher-ng, but I think I also made an error when I made the partitions: it was probably a wrong choice to choose "big files" inode repartition, that I used because I fought that it would preserve some disk space (the installation of this machine was on a 80GB only hard disk, so I tried to optimize --early optimization caught me anew, it seems-- the space, because lot of things to run on it).

So, I wonder if there is a way to fix this inode's size repartition? In a more general way, if people have some advices about that kind of issues (choosing the right cluster and partitions size, the right partition format, etc depending on the planned usage)? I know, those questions (and the error I supposed I made) may seem trivial for real administrators, but... I'm a simple programmer, not an admin.


Reply to: