SYSTÈME : df et bash pas d'accord (aucun espace libre...)

Depuis quelque temps (je croyais dans une précédente conversation que c’était dû à docker), j’ai des soucis de place disponible sur /. Pourtant, “df -h” m’indique qu’il y a encore pas mal de place :

adrien@localhost:~$ touch /tmp/coucou touch: impossible de faire un touch « /tmp/coucou »: Aucun espace disponible sur le périphérique adrien@localhost:~$ df -h Sys. fich. Taille Util. Dispo Uti% Monté sur rootfs 24G 14G 9,7G 58% / udev 10M 0 10M 0% /dev tmpfs 770M 7,7M 762M 1% /run /dev/disk/by-uuid/94923181-3318-4259-a065-b76b99eb19de 24G 14G 9,7G 58% / tmpfs 3,8G 644K 3,8G 1% /dev/shm tmpfs 3,8G 0 3,8G 0% /sys/fs/cgroup tmpfs 100M 24K 100M 1% /run/user tmpfs 5,0M 0 5,0M 0% /run/lock /dev/sda4 81G 55G 26G 69% /home /dev/sda1 248M 31M 218M 13% /boot /dev/sdb6 771G 684G 49G 94% /mnt/home
Voici ce que me dit “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=982768,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=787708k,mode=755) /dev/disk/by-uuid/94923181-3318-4259-a065-b76b99eb19de on / type btrfs (rw,noatime,thread_pool=32,compress=zlib,ssd,discard,space_cache) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime) tmpfs on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) /dev/sda4 on /home type btrfs (rw,noatime,thread_pool=32,compress=zlib,ssd,discard,space_cache) /dev/sda1 on /boot type ext4 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered,discard) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) /dev/sdb6 on /mnt/home type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered) fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)

Qu’en pensez-vous ?

Merci d’avance.

Bonjour,

Le /dev de udev ne fait que que 10 M,

En sus :

J’en déduit qu’il est indépendant de rootfs.

/dev est-il renseigné dans le fstab?
Est-il assigné à ces taches par le gestionnaire de bureau ?

Bonjour et merci de ta réponse.

Non, mon fstab est tout à fait conventionnel :

[code]proc /proc proc defaults 0 0

/ was on /dev/sdc2 during installation

UUID=94923181-3318-4259-a065-b76b99eb19de / btrfs
noatime,discard,rw,ssd,compress,thread_pool=32 0 1

/boot was on /dev/sdc1 during installation

UUID=0853b4bd-3264-4e2f-9aba-c718453f88aa /boot ext4 defaults,noatime,discard,errors=remount-ro 0 2

/home was on /dev/sdc4 during installation

UUID=b6108eb1-cd49-4dfe-a079-5ab0315d9b03 /home btrfs noatime,discard,rw,ssd,compress,thread_pool=32 0 2

swap was on /dev/sdc3 during installation

UUID=07bd63aa-794f-416f-8231-b8241d4d3f1f none swap sw 0 0

/dev/sdb6 /mnt/home/ ext4 defaults 0 2

UUID=553f3cd6-994c-4804-8338-7d145bf79960 /mnt/home/ ext4 defaults 0 2

/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/sdd1 /media/usb0 auto rw,user,noauto 0 0
[/code]

Du coup, qu’est-ce que ça signifie pour /dev ? Où puis-je chercher pour savoir avec quoi il est monté ?
Par ailleurs, je n’avais jamais vu cette histoire de cgroups. Est-ce que cela vient de docker, que j’ai installé récemment et purgé ?

Qu’est-ce que bash vient faire là-dedans ?
Habituellement je soupçonnerais un épuisement des inodes sur la racine. Chaque fichier créé même vide consomme un inode, dont le nombre est limité et fixé à la création du système de fichiers en ext2/3/4. Si c’est le cas, il faut peut-être faire du ménage. Mais ta racine est en brtfs, qui n’a pas censé avoir cette limitation. Qu’affiche [mono]df -i[/mono] ?

EDIT : J’ai vu le résultat dans ton fil ouvert sur la liste debian-user-french. Les 0 partout correspondent probablement au fait que btrfs n’a pas un pool d’inodes figé à la création.

Salut,

Ah bon …

[mono]systemd[/mono] imposé (si l’on n’y prend pas garde) en [mono]Jessie[/mono] (gel annoncé pour le 5 Novembre) et [mono]Sid[/mono].
Le gnome joufflu est-il de la partie ?

As-tu recueilli/accepté un bug en ton royaume ?

[quote=“Le Barde”]adrien@localhost:~$ touch /tmp/coucou
touch: impossible de faire un touch « /tmp/coucou »: Aucun espace disponible sur le périphérique
adrien@localhost:~$ [/quote]

Que contient [mono]/tmp[/mono] ?
Il y a-t-il un processus spécifique qui crache en ce dernier ?

Bonjour Adrien, le df -i donne

Sys. fich. Inodes IUtil. ILibre IUti% Monté sur rootfs 0 0 0 - / udev 982768 549 982219 1% /dev tmpfs 984634 699 983935 1% /run /dev/disk/by-uuid/94923181-3318-4259-a065-b76b99eb19de 0 0 0 - / tmpfs 984634 10 984624 1% /dev/shm tmpfs 984634 16 984618 1% /sys/fs/cgroup tmpfs 984634 16 984618 1% /run/user tmpfs 984634 5 984629 1% /run/lock /dev/sda4 0 0 0 - /home /dev/sda1 65536 241 65295 1% /boot /dev/sdb6 51322880 759401 50563479 2% /mnt/home
(Rq: pour des lignes il faut enlever la justification dans les courriels).

Je pense que les 0 viennent du système de fichiers qui n’est pas limité en inodes…
[edit: Je n’avais pas vu l’«edit» de Pascal, pas d’explications à vue de nez]

Que donne un
$ strace touch /tmp/gre

C’est quand-même bizarre, j’ai eu beau chercher un peu sur le Net, et je n’ai pas trouvé quelqu’un qui aurait eu le même problème que moi…

Merci François pour ta réponse !

Le problème des inodes est intéressant, d’autant qu’un [mono]du -Lxsh /sys[/mono] râle beaucoup… Je ne sais pas si c’est lié à ça ou si c’est autre chose… La même commande sur une machine “saine” me donne [mono]0 /sys/[/mono].

root@white-hat:/home/adrien# du -Lxsh /sys/ > coucou 2>&1 root@white-hat:/home/adrien# less coucou root@white-hat:/home/adrien# cat coucou du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/0:0:0:0/subsystem »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/0:0:0:0/device »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/2:0:0:0/subsystem »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/2:0:0:0/device »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/6:0:0:0/subsystem »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/6:0:0:0/device »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/6:0:0:2/subsystem »: Trop de niveaux de liens symboliques du: impossible d'accéder à « /sys/devices/platform/reg-dummy/subsystem/devices/pcspkr/input/input3/subsystem/input1/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/physical_node/subsystem/devices/0000:00:01.0/pci_bus/0000:01/subsystem/0000:00/device/0000:00:14.0/usb1/subsystem/devices/1-0:1.0/driver/module/holders/ehci_hcd/drivers/pci:ehci_hcd/0000:00:1a.0/usb3/driver/3-1/3-1.1/3-1.1:1.0/host6/subsystem/devices/host0/scsi_host/host0/subsystem/host2/device/target2:0:0/2:0:0:0/scsi_device/2:0:0:0/subsystem/0:0:0:0/device/bsg/0:0:0:0/subsystem/5:0:0:0/device/block/sr0/subsystem/sdc/device/driver/6:0:0:1/scsi_disk/6:0:0:1/subsystem/6:0:0:2/device »: Trop de niveaux de liens symboliques [etc.]

Voici le contenu de [mono]/tmp[/mono] :

adrien@localhost:~$ ls -lsa /tmp/ total 12 0 drwxrwxrwt 1 root root 468 oct. 25 15:30 . 4 drwxr-xr-x 1 root root 268 juin 7 13:19 .. 4 -rw-r--r-- 1 adrien adrien 6 oct. 25 00:08 blueman-applet-1000 0 drwxrwxrwt 1 root root 0 oct. 25 00:07 .font-unix 0 drwx------ 1 adrien adrien 22 oct. 25 00:09 gpg-nwq7xr 0 drwxrwxrwt 1 root root 0 oct. 25 00:08 .ICE-unix 0 drwx------ 1 adrien adrien 48 oct. 25 00:09 kde-adrien 0 drwx------ 1 adrien adrien 78 oct. 25 00:09 ksocket-adrien 0 drwx------ 1 adrien adrien 0 janv. 1 1970 orbit-adrien 0 drwx------ 1 Debian-gdm Debian-gdm 0 oct. 25 00:09 pulse-4WURuOfFBUtm 0 drwx------ 1 root root 0 oct. 25 00:07 pulse-PKdhtXMmr18n 0 drwx------ 1 adrien adrien 40 oct. 25 00:08 pulse-SHJ7wcss34yX 0 drwx------ 1 adrien adrien 20 oct. 25 00:08 ssh-fZnkB93nZZgq 0 drwx------ 1 root root 6 oct. 25 00:07 systemd-private-F6MboH 0 drwx------ 1 root root 6 oct. 25 00:07 systemd-private-OzIGxt 0 drwxrwxrwt 1 root root 0 oct. 25 00:07 .Test-unix 4 -r--r--r-- 1 root root 11 oct. 25 00:07 .X0-lock 0 drwxrwxrwt 1 root root 4 oct. 25 00:07 .X11-unix 0 drwxrwxrwt 1 root root 0 oct. 25 00:07 .XIM-unix adrien@localhost:~$

/sys est un pseudo système de fichiers, c’est normal que ça coince.
Tu as essayé le

Voici le résultat :

open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P#\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=31784, ...}) = 0 mmap(NULL, 2128920, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f23c0174000 mprotect(0x7f23c017b000, 2093056, PROT_NONE) = 0 mmap(0x7f23c037a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f23c037a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1725888, ...}) = 0 mmap(NULL, 3832352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f23bfdcc000 mprotect(0x7f23bff6b000, 2093056, PROT_NONE) = 0 mmap(0x7f23c016a000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19e000) = 0x7f23c016a000 mmap(0x7f23c0170000, 14880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f23c0170000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20o\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=137439, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23c0578000 mmap(NULL, 2213008, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f23bfbaf000 mprotect(0x7f23bfbc7000, 2093056, PROT_NONE) = 0 mmap(0x7f23bfdc6000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f23bfdc6000 mmap(0x7f23bfdc8000, 13456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f23bfdc8000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23c0577000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23c0576000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f23c0575000 arch_prctl(ARCH_SET_FS, 0x7f23c0576700) = 0 mprotect(0x7f23c016a000, 16384, PROT_READ) = 0 mprotect(0x7f23bfdc6000, 4096, PROT_READ) = 0 mprotect(0x7f23c037a000, 4096, PROT_READ) = 0 mprotect(0x60e000, 4096, PROT_READ) = 0 mprotect(0x7f23c059c000, 4096, PROT_READ) = 0 munmap(0x7f23c0579000, 132613) = 0 set_tid_address(0x7f23c05769d0) = 14471 set_robust_list(0x7f23c05769e0, 0x18) = 0 rt_sigaction(SIGRTMIN, {0x7f23bfbb59f0, [], SA_RESTORER|SA_SIGINFO, 0x7f23bfbbe8d0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f23bfbb5a80, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f23bfbbe8d0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 brk(0) = 0x17f2000 brk(0x1813000) = 0x1813000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1607728, ...}) = 0 mmap(NULL, 1607728, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f23c03ec000 close(3) = 0 open("/tmp/gre", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 dup2(3, 0) = 0 close(3) = 0 dup2(0, 0) = 0 utimensat(0, NULL, NULL, 0) = 0 close(0) = 0 close(1) = 0 close(2) = 0 exit_group(0) = ?

Par contre, là j’avoue que je suis dépassé !

Ben là, il n’a pas signalé d’erreur:

[quote]open("/tmp/gre", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
[/quote]création du fichier, pas de souci, identifiant = 3[quote]dup2(3, 0) = 0
close(3) = 0[/quote]
fermeture du fichier, pas de souci.

Tu dois avoir un fichier /tmp/gre non?

Oui oui, mais j’ai redémarré la machine depuis (et pour l’instant pas de problème de ce côté-là). Il s’agit de ma station de travail / utilisation perso, donc je ne peux pas trop rester plusieurs jours avec un système instable.

Avec l’utilisation que j’en fais, la machine est souvent allumée et lorsque je l’éteins, c’est à coups de [mono]pm-suspend[/mono] ou [mono]pm-hibernate[/mono]. Du coup, une éventuelle fuite de mémoire ou d’inodes s’accumule avec le temps.

En temps normal, sur ma machine perso j’ai des uptimes de l’ordre de trois mois, donc le système est relativement stable. Le problème que je relate ici et sur la liste de diffusion de Debian concerne cette même machine au bout de quelques jours seulement (environ, je n’ai pas le temps exact). Il y a donc apparemment bel et bien une fuite de quelque chose quelque part…

Vérifie que tu n’es pas /tmp sur un tmpfs?

Tu peux eventuellement forcer la chose en mettant
RAMTMP="yes"
dans /etc/default/tmpfs

Cela permettra de voir si le souci vient de /tmp ou du reste. Mais pour le moment je n’ai pas le début du commencement de l’ombre d’une ébauche d’explication.

Au départ, j’avais supposé un truc pas compliqué du tout…

J’ai installé docker, qui permet d’utiliser des containers pour séparer des processus… sorte de machine virtuelle sans virtualisation. D’après ce que j’ai cru comprendre, ça utilise les cgroups, voilà pourquoi je me suis entêté sur la question des cgroups.

Comme je ne veux pas avoir confiance dans les conteneurs donnés par Docker, j’ai créé de toutes pièces une première image Debian stable avec cette méthode (avec mkimage.sh).

J’ai ensuite créé une nouvelle image à partir de la première en y mettant le code de mon application node.js en cours de développement.

Dedans, j’y ai copié sauvagement les fichiers de mon application, dont les dépendances, qui sont des liens symboliques vers des choses qui gisent dans [mono]/usr/lib/node_modules/sails/[/mono] (j’utilise le framework Sailsjs, dont le générateur de projet fait des liens symboliques pour toutes les dépendances qui sont déjà installées en global sur la machine).

Il se trouve que c’est grosso modo à ce moment-là que j’ai commencé à avoir des soucis de latence et d’espace disponible, c’est pourquoi j’ai associé mon problème à ça. Je me suis dit bêtement qu’un container docker allant chercher un lien symbolique dans une partition btrfs n’est pas la chose ni la plus courante qui soit, ni n’utilise les technologies les plus stables… Mais peut-être cela n’a-t-il aucun lien ?

Par ailleurs, les recherches web sur les termes “docker no space left on device”, “docker symbolic link btrfs” ou encore “docker btrfs inode leak” donnent des choses diverses et variées, mais qui ne m’éclairent pas pour autant… Depuis, j’ai fait un [mono]apt-get purge docker*[/mono] et j’ai viré toutes les images restantes à grands coupe de [mono]rm -rf[/mono].

Pour [mono]/tmp[/mono], voici ce que j’ai :

root@localhost:/home/adrien# mount | grep tmp udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=982877,mode=755) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=787708k,mode=755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) tmpfs on /run/user type tmpfs (rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) root@localhost:/home/adrien#

Je ne connais pas bien les cgroups, cela limite les ressources pour des processus, on pourrait imaginer que les ressources allouées au shell soient consommées par les processus lancés et donc qu’il ne peut plus rien créer. Cela expliquerait tout. Mais il faut que quelqu’un connaissant les cgroups confirme.

En tous cas, merci pour ton aide (et à tout le monde également). Le problème n’est pas encore résolu, mais je tâcherai de refaire surface quand les problèmes reviendront ; je pourrai alors tester plus facilement les choses dont nous avons parlé ici.

Je pense en tous cas que le système swappe, ce qui explique la lenteur de la machine à ce moment-là. Mais ce qui est bizarre, c’est que [mono]htop[/mono] ne montre pas de signe de problème. Tout au plus le load average monte à 0.9 au lieu de 0.5…

Tu devrais peut-être y regarder de plus près Évolutions techniques de systemd

[quote]Chaque processus lancé est tracé par son heure de démarrage, de fin, son PID et son code de retour ; permettant d’analyser les anomalies.
[/quote]

[mono]$ systemctl list-units
$ systemctl status truc_machin.service

grep truc_machin /var/log/messages

$ systemd-cgls
$ ps waxf -eo ‘user,pid,cgroup,command’[/mono]