Falha ao adicionar / executar / systemd / ask-password no diretório watch: não resta espaço no dispositivo?


34

Alguém sabe por que eu tenho essa mensagem com a nova atualização do samba no ubuntu 16.04.1?

Paramétrage de samba (2:4.3.9+dfsg-0ubuntu0.16.04.3) ...
Failed to add /run/systemd/ask-password to directory watch: No space left on device: 

Como tenho muito espaço, não entendo:

df -h
Sys. de fichiers                  Taille Utilisé Dispo Uti% Monté sur
udev                                 16G       0   16G   0% /dev
tmpfs                               3,2G     11M  3,2G   1% /run
/dev/sda2                           107G     49G   53G  48% /
tmpfs                                16G    184K   16G   1% /dev/shm
tmpfs                               5,0M    4,0K  5,0M   1% /run/lock
tmpfs                                16G       0   16G   0% /sys/fs/cgroup
/dev/sdi2                           367G    343G  5,2G  99% /media/divers
/dev/sda1                           110G    366M  104G   1% /opt
/dev/sdm1                           147G    136G   11G  93% /media/nfsmedia/syno/usb4
/dev/sdq1                            74G     69G  1,1G  99% /media/nfsmedia/syno/usb8
/dev/sdp1                           459G    453G  5,6G  99% /media/nfsmedia/syno/usb1
/dev/sde2                           735G    684G   14G  99% /media/series
/dev/sdo1                           1,8T   1015G  726G  59% /media/nfsmedia/syno/usb3
/dev/sdr1                            74G     68G  1,6G  98% /media/nfsmedia/syno/usb7
/dev/mapper/RAIDSTOCK-RAID5FSTOCK   9,0T    7,3T  1,4T  85% /media/RAIDFORSTOCK
/dev/mapper/RAID1FORDOCK-DOCK       550G    303G  220G  58% /media/DOCK
cgmfs                               100K       0  100K   0% /run/cgmanager/fs
tmpfs                               3,2G       0  3,2G   0% /run/user/1004
//192.168.6.12/vigilian             1,9T    1,7T  179G  91% /media/smbseries/nsa
//192.168.6.11/NASA                 930G    807G  123G  87% /media/smbseries/nasa
tmpfs                               3,2G     12K  3,2G   1% /run/user/123
tmpfs                               3,2G       0  3,2G   0% /run/user/1000

Respostas:


6

Não tenho reputação suficiente para comentar a resposta aceita, mas queria dizer que ela não se limita ao CrashPlan. O Dropbox e outras plataformas de compartilhamento de arquivos usam relógios inotify por inode para detectar quando uma sincronização upstream precisa ocorrer. Os detectores de malware podem ter relógios nos diretórios. Outras ferramentas de backup além do CrashPlan também podem.

Para ver o que está consumindo relógios inotify, use lsof:

sudo lsof -K | grep inotify | (less||more||pg)

70

Conforme discutido em um relatório de bug da Red Hat , verifica-se que o serviço de backup da Crashplan é o culpado mais provável. Ele usa muitos relógios inotify e, eventualmente, consome todos eles.

A correção imediata é executar:

sudo -i
echo 1048576 > /proc/sys/fs/inotify/max_user_watches
exit

para disponibilizar mais relógios.

A correção a longo prazo é editar o arquivo /etc/sysctl.confpara incluir a linha:

fs.inotify.max_user_watches=1048576

Sim, eu já vi, mas não era assim, já que não tenho nada parecido instalado. Parece que iwas Samba relacionados ou RAID relacionadas
vigilian

10
Isso me ajudou, eu tenho Crashplan
Brian Low

mas mesmo assim ainda funciona. Esteja ciente de que seria um problema semelhante com muita notificação mdadm ou notificação smaba.
Vigilian

Me ajudou na kali linux
Tim Jonas
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.