Problème d'espace disque sur un fileserver [résolu]

Support Debian
#1

Bonjour tout le monde,

Me voilà fasse un problème curieux. Il faut savoir que ce serveur est uniquement sous console.

Voilà, mon problème est que j’ai un fileserver avec deux disques durss de 1To en raid1, est que j’ai des alertes sur l’espace disque:

Filesystem           Size  Used Avail Use% Mounted on
rootfs                48G   48G     0 100% /
udev                  10M     0   10M   0% /dev
tmpfs                795M  924K  794M   1% /run
/dev/mapper/vg-root   48G   48G     0 100% /
tmpfs                5.0M     0  5.0M   0% /run/lock
tmpfs                1.6G     0  1.6G   0% /run/shm
/dev/md0             236M   41M  184M  18% /boot
/dev/mapper/vg-home  788G  577G  171G  78% /home

Ce qui me donne des erreurs du type:

:~# ls -bash: cannot create temp file for here-document: No space left on device
-bash: cannot create temp file for here-document: No space left on device

J’ai donc parcouru notre ami google et j’ai trouvé diverses choses comme apt-get autoclean ect… Mais il ne s’agit pas réellement d’un problème d’espace disque (enfin je suppose), car si je redémarre le serveur les valeurs retombent à 44% pour la racine /. De plus le système dispose normalement de 5% pour le superuser (root), ce qui n’est pas le cas ici.

Je bloque donc sur l’origine du problème. J’ai faits quelques tests sur les DD et les résultats de smartctl me disent qu’un problème est survenue sur sdb (écriture impossible & secteur défectueux), j’ai donc changé sdb et lancé la reconstruction du raid1 avec mdadm et tout c’est bien déroulé.

Je n’ai donc plus d’erreur disque dur et la taille réelle de / est 44% et non 100% comme me l’indique un df -h (et je n’ai rien dans les logs {debug; dmesg; kern.log; messages; syslog}…).

Si vous avez des pistes je suis preneur.

Merci par avance pour votre aide.

#2

bonjour

Ai-je bien compris ta question : j’ai 44% d’espace disque utilisé sur /, et “df” m’indique pourtant 100%; et le remplissage est confirmé par des messages d’erreur. C’est ça ?

tu as (uniquement?) deux disques sda et sdb montés en raid 1. si je lis bien le df-h, /boot est directement sur une partition du raid, le reste (root et home) faisant appel à des groupes de volume gérés par LVM.
Il faudrait voir comment sont réellement construits ces volumes, voir les vérifier .
pvdisplay
vgdisplay
mount (pour voir les formatages)

Et je ne comprends pas par quelle manip tu obtiens le chiffre de 44%, puisque ce n’est pas df -h qui te le donne. la commande ‘du’ ?

#3

Bonjour

Le retour de cette ligne de commande, lancée depuis le compte root, pourra aussi apporter quelques informations supplémentaires :

lsblk -o TYPE,SIZE,NAME,FSTYPE,UUID,LABEL,MOUNTPOINT
#4

Tu veux dire qu’après un redémarrage la racine est occupée à 44% puis cela monte à 100% au bout d’un moment ? Dans ce cas il pourrait s’agir d’un ou plusieurs fichiers temporaires qui grossissent et ne sont libérés qu’à l’arrêt du système (ou plus exactement du processus qui les maintient ouvert). Tu peux rechercher dans /tmp et /var qui sont normalement les seuls endroits où ce genre de fichier peut être. Il se peut qu’ils ne soient pas visibles dans l’arborescence, il faut alors rechercher les fichiers supprimés (deleted) mais encore ouverts avec lsof.

La réserve de 5% ne s’applique pas aux processus système qui s’exécutent en tant que root.

#5

Bonjour,

Merci pour vos réponses.

Le retour du lsblk -o TYPE,SIZE,NAME,FSTYPE,UUID,LABEL,MOUNTPOINT:

TYPE    SIZE NAME                 FSTYPE            UUID                                   LABEL    MOUNTPOINT
disk  931.5G sda                                                                                    
part    243M ├─sda1               linux_raid_member ec59d93e-bf1e-918f-5b45-5536753334ea   debian:0 
raid1   243M │ └─md0              ext4              4e6ecda6-b1a4-4011-928f-93836252ddad            /boot
part  931.3G └─sda2               linux_raid_member 439e64e2-0379-490c-072b-4d6bf5266ecb   debian:1 
raid1 931.3G   └─md1              LVM2_member       LiPefI-SMVP-53mh-GEIG-y1fg-lGpc-aGsnlI          
lvm    48.1G     ├─vg-root (dm-0) ext4              feeff1a4-d258-4b94-937f-c468238ce5a0            /
lvm     7.6G     ├─vg-swap (dm-1) swap              7d5c5158-c182-497e-badb-b83583a5a7ff            [SWAP]
lvm     800G     └─vg-home (dm-2) ext4              f01e4a07-1e2c-421e-ad12-f6b392bca8cc            /home
disk  931.5G sdb                                                                                    
part    243M ├─sdb1               linux_raid_member ec59d93e-bf1e-918f-5b45-5536753334ea   debian:0 
raid1   243M │ └─md0              ext4              4e6ecda6-b1a4-4011-928f-93836252ddad            /boot
part  931.3G └─sdb2               linux_raid_member 439e64e2-0379-490c-072b-4d6bf5266ecb   debian:1 
raid1 931.3G   └─md1              LVM2_member       LiPefI-SMVP-53mh-GEIG-y1fg-lGpc-aGsnlI          
lvm    48.1G     ├─vg-root (dm-0) ext4              feeff1a4-d258-4b94-937f-c468238ce5a0            /
lvm     7.6G     ├─vg-swap (dm-1) swap              7d5c5158-c182-497e-badb-b83583a5a7ff            [SWAP]
lvm     800G     └─vg-home (dm-2) ext4              f01e4a07-1e2c-421e-ad12-f6b392bca8cc            /home

J’ai en effet uniquement 2 DD de 1To en RAID1, le tout géré avec LVM:

Le vgdisplay:

  --- Volume group ---
  VG Name               vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               931.27 GiB
  PE Size               4.00 MiB
  Total PE              238405
  Alloc PE / Size       219078 / 855.77 GiB
  Free  PE / Size       19327 / 75.50 GiB
  VG UUID               Ed986V-LLN7-oklz-icmw-xTHN-yL09-88dA1L

Le lvdisplay:

--- Logical volume ---
  LV Path                /dev/vg/swap
  LV Name                swap
  VG Name                vg
  LV UUID                MQolvI-Qs9F-HtyS-onTp-YgwP-iWOc-kvesWe
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 2
  LV Size                7.63 GiB
  Current LE             1953
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
   
  --- Logical volume ---
  LV Path                /dev/vg/root
  LV Name                root
  VG Name                vg
  LV UUID                6jJdlk-78DV-e5Bn-xoLR-QeZ3-PEUf-nhFy2l
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                48.14 GiB
  Current LE             12325
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0
   
  --- Logical volume ---
  LV Path                /dev/vg/home
  LV Name                home
  VG Name                vg
  LV UUID                kjC3Vc-cT8V-Vvb2-l3hZ-NzLa-95nT-eDHlAM
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                800.00 GiB
  Current LE             204800
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

Le mount:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014685,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=813060k,mode=755)
/dev/mapper/vg-root on / type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1626100k)
/dev/md0 on /boot type ext4 (rw,nosuid,nodev,noexec,noatime,user_xattr,acl,barrier=1,data=ordered)
/dev/mapper/vg-home on /home type ext4 (rw,nosuid,nodev,noatime,user_xattr,acl,barrier=1,data=ordered)

Et je ne comprends pas par quelle manip tu obtiens le chiffre de 44%, puisque ce n’est pas df -h qui te le donne. la commande ‘du’ ?

J’obtiens le 44% après le reboot serveur (pendant ~16/18 heures) puis ça repasse à 100% sur la racine.

Dans ce cas il pourrait s’agir d’un ou plusieurs fichiers temporaires qui grossissent et ne sont libérés qu’à l’arrêt du système (ou plus exactement du processus qui les maintient ouvert). Tu peux rechercher dans /tmp et /var qui sont normalement les seuls endroits où ce genre de fichier peut être.

Un du -sh de /tmp et /var m’indique que les répertoires ne dépasse pas 500Mo:

4.0K	/tmp
410M	/var

Je vais voir du côté lsof et je reviens vers vous.
Merci beaucoup pour votre aide dans tout les cas.

#6

L’augmentation est progressive ou brutale ? Ça prend combien de temps pour passer de plus de 44% à 100% ?
Si c’est brutal, est-ce que ça se produit à une heure précise (qui serait liée à une tâche périodique) ou plutôt au bout d’un temps fixe après le démarrage ?

Au moins la racine est en ext4, ce qui exclut l’hypothèse des bizarreries de calcul de l’espace libre/occupé liées à btrfs.

#7

'augmentation est progressive ou brutale ?

C’est brutale, très rapide ! 10Go en moins d’une minute. J’avais pas fait le lien… mais l’alerte viens toujours entre 6h20 et 6h30 (6h24 ce matin), il pourrais donc s’agir d’un tache cron… :frowning:

Voici les logs cron (et smartd) que trouve juste avant le problème :

Nov 30 06:17:01 _fileserver_ /USR/SBIN/CRON[30866]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 30 06:23:13 _fileserver_ smartd[2909]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 116 to 115
#8

Sauf erreur, c’est l’heure des tâches cron quotidiennes (/etc/cron.daily) où sont effectuées des opérations de maintenance parfois lourdes (comme updatedb pour mise à jour de la base de données de locate).

Edit : vérification faite dans /etc/crontab, cron.daily se déclenche à 6h25.

#9

Ok donc mes alertes datent de 6H24 et 6h20 pour celles d’avant hier, donc rien à voir avec les cron.daily… Cependant il y a forcément un lien avec l’heure, le tout est de découvrir lequel :smirk:

C’est déjà un progrés ! Je vais check les logs que je trouve en rapport avec le créneau horaire.

Merci beaucoup pour ta rapidité de retour :+1:

#10

Hello tout le monde :slight_smile:

Bon je pense avoir trouvé le problème… Un cron qui tourne tous les jours à 6 heures (AM).
0 6 * * * clamscan -ir /home

Reste à voir pourquoi (MàJ du soft ou de la base antiviral, un fichier cassé ou encore un secteur en defaut sur sda… je vais bien voir…)

Le sujet principal étant visiblement réglé, je vais passer le post en résolu :slight_smile:
Merci beaucoup pour votre aide !

Bon courage et bonne journée !