ls hängt für ein bestimmtes Verzeichnis

Es gibt ein bestimmtes Verzeichnis ( /var/www), bei dessen Ausführung ls(mit oder ohne bestimmte Optionen) der Befehl hängen bleibt und nie ausgeführt wird. Es gibt nur ungefähr 10-15 Dateien und Verzeichnisse in /var/www. Meist nur Textdateien. Hier einige recherchierende Informationen:

[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% /

findfunktioniert gut. Ich kann auch eintippen cd /var/www/und TAB drücken, bevor ich die Eingabetaste drücke, und es wird eine Liste aller darin enthaltenen Dateien / Verzeichnisse angezeigt:

[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/

Ich musste meine Terminalsitzungen mehrmals wegen des lsHängens beenden:

[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 scheint keinen Einfluss auf die Prozesse zu haben, auch nicht als sudo.

Was kann ich noch tun, um dieses Problem zu untersuchen? Es begann gerade zufällig heute.

AKTUALISIEREN

dmesgist eine große Liste von Dingen, die hauptsächlich mit einer externen USB-Festplatte zu tun haben, die ich zu oft gemountet habe und deren maximale Mount-Anzahl erreicht wurde. Im unteren Bereich dmesgsehe ich Folgendes:

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

Und strace ls /var/www/spuckt auch eine ganze Menge Informationen aus. Ich weiß nicht, was hier nützlich ist ... Die letzten paar Zeilen:

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)                           = ?

Lauf strace ls /var/www/und schau, woran es hängt. Es hängt mit Sicherheit an E / A - das bedeutet der DStatus in Ihrer psAusgabe (und da killdies nicht hilft, ist es einer der unterbrechungsfreien E / A-Systemaufrufe). Die meisten Hänge betreffen einen NFS-Server, der zu Gott gegangen ist, aber basierend auf Ihrem dfist das hier nicht der Fall. Eine schnelle Überprüfung dmesgauf Dateisysteme oder Festplatten kann sich für alle Fälle lohnen.

Ich hatte ein Problem mit den gleichen Symptomen. Es stellte sich heraus, dass ich in diesem Verzeichnis einen Symlink zu einem SMB-Mount über GVFS hatte.

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

Normalerweise wird lssofort abgeschlossen, ob die Freigabe bereitgestellt wurde oder nicht. Aber in diesem Fall hatte ich die Maschine angehalten und wieder aufgenommen, und das Reittier lief im Allgemeinen schlecht. Das erneute Einhängen der Freigabe behebt das Problem.

Ich hatte das gleiche Problem.

Ordnung ist ein Verzeichnis der Eingabe Auflistung es hängt, finden Arbeiten, Tab vollständig hängt, und einige Ordner unterhalb tun Arbeit. Sehr kopfkratzend-komisch.

Das Lesen dieses Threads bei Server Fault hat mich auf einen logischen Pfad zur Lösung geführt.

Das hatte mit NAS zu tun, und NAS wurde normalerweise als "automount" bezeichnet. Dadurch wurde mir klar, dass ich kürzlich meine fstab auf einige USB-Laufwerke "automount" umgestellt hatte, wenn sie vorhanden waren, aber wie gewohnt weitermachten, wenn sie nicht vorhanden waren.

Ich ging dann wie folgt vor:

1. Hängen Sie die Partition ab, die das überfällige Verzeichnis enthält.
2. Bearbeiten Sie die fstab und konvertieren Sie alle automounts entweder auf auskommentiert oder ohne auto.
3. Laden Sie SystemD neu, wenn Sie es haben: systemctl --system daemon-reload
4. mount -a

Versuchen Sie erneut, das Verzeichnis aufzurufen, und fühlen Sie sich warm, als hätten Sie das Problem behoben.

Die Vorschläge von Womble sind ausgezeichnet, und Sie sollten diese zuerst ausprobieren. Wenn sie es jedoch nicht beheben, hatte ich dieses Problem, wenn ein Dateisystem selbstinkonsistent geworden ist (durch flockige Hardware, obskure Kernel-Fehler oder sogar kosmische Strahlung).

Wenn Sie glauben, dass dies der Fall sein könnte, können Sie einen fsck-Neustart erzwingen, indem Sie Folgendes tun touch /forcefsck; reboot. Beobachten Sie, was beim Booten angezeigt wird, um festzustellen, ob das fsck Inkonsistenzen feststellt.

Warnung : Dadurch werden alle an den Computer angeschlossenen Dateisysteme überprüft. Tun Sie dies nicht, wenn Sie auch ein Multi-Petabyte-Disc-Array angeschlossen haben. Dies kann Tage dauern . fsckDas Speichern von Dateisystemen kann auch zu Datenverlust führen. Wenn Sie tatsächlich Inkonsistenzen in Ihrem Dateisystem haben, ändert e2fsck diese von einer, die richtig aussieht, aber nicht ganz funktioniert, zu einer, die richtig funktioniert, aber möglicherweise nicht alles enthält, was Sie erwarten.

Ich hatte genau die Symptome, die Sie beschrieben haben. Um das Problem zu beheben, musste ich nur die DNS-Serveradressen reparieren. Wir hatten den NAS in ein neues Netzwerk verlegt, in dem die DNS-Serveradressen aktualisiert werden mussten. Die Adressen wurden statisch zugewiesen, aber in der QNAP-Weboberfläche habe ich sie aktualisiert, um sie automatisch zuzuweisen.

In der Hoffnung, dass dies hilfreich sein wird, hatte ich die oben genannten Symptome, die durch die Verwendung dockerund docker composemit dem AUFS-Treiber in Ubuntu 14.04 verursacht wurden. ls <dir>hing und strace ls <dir>zeigte, dass es am getdentsAnruf hing . Durch das Stoppen aller laufenden Container konnte ich das Laufwerk wie erwartet verwenden.

Wenn Sie strace ls / var / www / ausführen, wissen Sie, was nicht stimmt. Ich hatte ein ähnliches Problem für / dir und mithilfe von strace konnte ich feststellen, dass es sich um ein NAS-Mount handelt, das es verursacht hat. Das Abmelden dieses NAS hat das Problem behoben.