Si blocca per una determinata directory

C'è una directory particolare ( /var/www), che quando corro ls(con o senza alcune opzioni), il comando si blocca e non si completa mai. Ci sono solo circa 10-15 file e directory in /var/www. Principalmente solo file di testo. Ecco alcune informazioni investigative:

[me@server www]$ df .
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_dev-lv_root
                       50G   19G   29G  40% /

[me@server www]$ df -i .
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_dev-lv_root
                        3.2M    435K    2.8M   14% /

findfunziona bene. Inoltre posso digitare cd /var/www/e premere TAB prima di premere invio e verrà visualizzato l'elenco di completamento delle schede con successo di tutti i file / directory presenti:

[me@server www]$ cd /var/www/
cgi-bin/         create_vhost.sh  html/            manual/          phpMyAdmin/      scripts/         usage/
conf/            error/           icons/           mediawiki/       rackspace        sqlbuddy/        vhosts/
[me@server www]$ cd /var/www/

Ho dovuto uccidere le mie sessioni terminali più volte a causa dell'impiccagione ls:

[me@server ~]$ ps | grep ls
gdm       6215  0.0  0.0 488152  2488 ?        S<sl Jan18   0:00 /usr/bin/pulseaudio --start --log-target=syslog
root     23269  0.0  0.0 117724  1088 ?        D    18:24   0:00 ls -Fh --color=always -l
root     23477  0.0  0.0 117724  1088 ?        D    18:34   0:00 ls -Fh --color=always -l
root     23579  0.0  0.0 115592   820 ?        D    18:36   0:00 ls -Fh --color=always
root     23634  0.0  0.0 115592   816 ?        D    18:38   0:00 ls -Fh --color=always
root     23740  0.0  0.0 117724  1088 ?        D    18:40   0:00 ls -Fh --color=always -l
me       23770  0.0  0.0 103156   816 pts/6    S+   18:41   0:00 grep ls

kill non sembra avere alcun effetto sui processi, anche come sudo.

Cos'altro dovrei fare per indagare su questo problema? Oggi è iniziato a caso.

AGGIORNARE

dmesgè un grande elenco di cose, principalmente legate a un HDD USB esterno che ho montato troppe volte e che è stato raggiunto il numero massimo di montaggi, ma penso che sia un problema non correlato. In fondo a dmesgquesto sto vedendo:

INFO: task ls:23579 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls            D ffff88041fc230c0     0 23579  23505 0x00000080
 ffff8801688a1bb8 0000000000000086 0000000000000000 ffffffff8119d279
 ffff880406d0ea20 ffff88007e2c2268 ffff880071fe80c8 00000003ae82967a
 ffff880407169ad8 ffff8801688a1fd8 0000000000010518 ffff880407169ad8
Call Trace:
 [<ffffffff8119d279>] ? __find_get_block+0xa9/0x200
 [<ffffffff814c97ae>] __mutex_lock_slowpath+0x13e/0x180
 [<ffffffff814c964b>] mutex_lock+0x2b/0x50
 [<ffffffff8117a4d3>] do_lookup+0xd3/0x220
 [<ffffffff8117b145>] __link_path_walk+0x6f5/0x1040
 [<ffffffff8117a47d>] ? do_lookup+0x7d/0x220
 [<ffffffff8117bd1a>] path_walk+0x6a/0xe0
 [<ffffffff8117beeb>] do_path_lookup+0x5b/0xa0
 [<ffffffff8117cb57>] user_path_at+0x57/0xa0
 [<ffffffff81178986>] ? generic_readlink+0x76/0xc0
 [<ffffffff8117cb62>] ? user_path_at+0x62/0xa0
 [<ffffffff81171d3c>] vfs_fstatat+0x3c/0x80
 [<ffffffff81258ae5>] ? _atomic_dec_and_lock+0x55/0x80
 [<ffffffff81171eab>] vfs_stat+0x1b/0x20
 [<ffffffff81171ed4>] sys_newstat+0x24/0x50
 [<ffffffff810d40a2>] ? audit_syscall_entry+0x272/0x2a0
 [<ffffffff81013172>] system_call_fastpath+0x16/0x1b

Inoltre, strace ls /var/www/sputa un sacco di informazioni. Non so cosa sia utile qui ... L'ultima manciata di righe:

ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=145, ws_xpixel=0, ws_ypixel=0}) = 0
stat("/var/www/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/var/www/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD)                       = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 16 entries */, 32768)    = 488
getdents(3, /* 0 entries */, 32768)     = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 9), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3093b18000
write(1, "cgi-bin  conf  create_vhost.sh\te"..., 125cgi-bin  conf  create_vhost.sh      error  html  icons  manual  mediawiki  phpMyAdmin  rackspace  scripts  sqlbuddy  usage   vhosts
) = 125
close(1)                                = 0
munmap(0x7f3093b18000, 4096)            = 0
close(2)                                = 0
exit_group(0)                           = ?

Corri strace ls /var/www/e vedi cosa si blocca. Certamente è appeso all'I / O - questo è ciò che significa lo Dstato psnell'output (e poiché killnon aiuta, è una delle ininterrotte syscalls I / O). La maggior parte degli hang coinvolge un server NFS che è andato a dio, ma basato sul tuo dfche non è il caso qui. dmesgPotrebbe essere utile un rapido controllo di qualsiasi cosa relativa a filesystem o dischi, per ogni evenienza.

Ho avuto un problema con gli stessi sintomi. Si è scoperto che avevo un link simbolico in quella directory a un mount SMB su GVFS.

lrwxrwxrwx  1 alex alex        45 Sep 16  2011 foo -> /home/alex/.gvfs/bar on foo/data/

Normalmente lssi completerebbe all'istante indipendentemente dal fatto che la condivisione fosse montata o meno. Ma in questo caso avevo sospeso e ripreso la macchina e la montatura si stava comportando male in generale. Il nuovo montaggio della condivisione ha risolto il problema.

Stavo riscontrando lo stesso problema.

Entrare una directory va bene, elencando si blocca, trovare lavori, tab si blocca completi, e alcune cartelle sotto fare il lavoro. Molto stranamente graffiante.

La lettura di questo thread su Server Fault mi ha portato su un percorso logico verso la soluzione.

Il fatto che avesse a che fare con il NAS, e il NAS che veniva comunemente impostato come "automount", mi fece capire che di recente avevo cambiato il mio fstab in "automount" di alcune unità USB se erano presenti ma continuavano normalmente quando non lo erano.

Ho quindi proceduto come segue:

1. Smonta la partizione contenente la directory delinquent.
2. Modifica fstab e converti tutto l'automount in commento o senza auto.
3. Ricarica SystemD se ce l'hai: systemctl --system daemon-reload
4. mount -a

Prova ad accedere di nuovo alla directory e ottieni la calda sensazione di aver risolto il problema.

I suggerimenti di Womble sono eccellenti, e dovresti provarli prima, ma se non lo risolvono ho avuto questo problema quando un filesystem è diventato incoerente (attraverso hardware traballante, bug oscuri del kernel o persino raggi cosmici).

Se pensi che potrebbe essere quello, puoi forzare un fsck al riavvio facendo touch /forcefsck; reboot. Guarda cosa dice all'avvio, per vedere se fsck rileva eventuali incongruenze.

Avvertenza : questo bloccherà tutti i filesystem collegati alla macchina; non farlo se si dispone anche di un array di dischi multi-petabyte, potrebbero essere necessari giorni . fscki filesystem possono anche portare alla perdita di dati; se hai davvero delle incongruenze nel tuo file system, e2fsck lo cambierà da uno che sembra giusto ma non funziona del tutto, a uno che funziona bene ma potrebbe non contenere tutto ciò che ti aspetti.

Ho avuto gli stessi sintomi esatti che hai descritto. Per risolvere il problema, tutto quello che dovevo fare era correggere gli indirizzi del server DNS. Avevamo spostato il NAS in una nuova rete, che richiedeva l'aggiornamento degli indirizzi del server DNS. Gli indirizzi sono stati assegnati staticamente, ma nell'interfaccia Web di QNAP l'ho aggiornato per assegnare automaticamente.

Nella speranza che ciò possa essere d'aiuto, ho avuto i suddetti sintomi causati dall'uso dockere docker composecon il driver AUFS in Ubuntu 14.04. ls <dir>era sospeso e ha strace ls <dir>mostrato che era appeso alla getdentschiamata. L'arresto di tutti i contenitori in esecuzione mi ha permesso di iniziare a utilizzare l'unità come previsto.

L'esecuzione di strace ls / var / www / ti darà un'idea di ciò che è sbagliato. Ho avuto un problema simile per / dir e usando strace sono stato in grado di individuare che era un mount NAS che lo ha causato. Smontare quel NAS ha risolto il problema.