Frage ls hängt für ein bestimmtes Verzeichnis


Es gibt ein bestimmtes Verzeichnis (/var/www), dass wenn ich renne ls (mit oder ohne einige Optionen) hängt der Befehl und wird nie abgeschlossen. Es gibt nur ungefähr 10-15 Dateien und Verzeichnisse in /var/www. Meistens nur Textdateien. Hier sind einige investigative 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% /

find funktioniert gut. Auch ich kann eintippen cd /var/www/ und drücken Sie TAB, bevor Sie die Eingabetaste drücken. Es wird eine Tab-Vervollständigungsliste aller Dateien / Verzeichnisse darin 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 Terminalsessions mehrmals wegen der ls hängend:

[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 soll ich noch tun, um dieses Problem zu untersuchen? Es ist einfach zufällig passiert heute.

AKTUALISIEREN

dmesg Es ist eine große Liste von Dingen, die hauptsächlich mit einer externen USB-Festplatte zu tun haben, die ich zu oft montiert habe und die maximale Anzahl an Montierungen wurde erreicht, aber das ist ein unzusammenhängendes Problem, denke ich. Nahe dem Boden von dmesg Ich sehe das:

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 auch, strace ls /var/www/ spuckt 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)                           = ?

30
2018-03-07 23:48


Ursprung


habe diese Frage mit den gleichen Symptomen gefunden. Wie sich herausstellte, hatte ich ein Remote-Dateisystem, das über sshfs mit einer angehängten Verbindung verbunden war. - bohdan_trotsenko
Was machst du mit sshfs? Ich habe das gleiche Problem. - Menelaos Bakopoulos
ls hing für mich auf getdents () für ein bestimmtes Verzeichnis. Das Problem löste sich selbst, nachdem ich ausgehängt habe, ran xfs_check, ran xfs_repair und remounted, obwohl keine Probleme gefunden wurden. - Leons
Ich musste 'kill -9' benutzen, um steckengebliebene Ls aufzuräumen. - flickerfly


Antworten:


Lauf strace ls /var/www/ und sehen, woran es hängt. Es hängt sicherlich an I / O - das ist es D Staat in deinem ps Ausgabemittel (und seit kill hilft nicht, es ist einer der unterbrechungsfreien E / A-Systemaufrufe). Die meisten hängen von einem NFS-Server, der zu Gott gegangen ist, aber basierend auf Ihrem df das ist hier nicht der Fall. Eine schnelle Überprüfung von dmesg Alles, was mit Dateisystemen oder Festplatten zu tun hat, kann sich für den Fall der Fälle lohnen.


22
2018-03-07 23:52



NFS könnte immer noch der Fall sein. Ob ls ist ein Alias ​​für etwas, das versucht, Symlinks zu dereferenzieren, um zu finden, auf was sie zeigen, es könnte hängen, wenn der Symlink auf ein totes NFS-Mount zeigt. - Patrick
Gah, bemerkte nicht, dass es ein war df . und nicht voll df. Es könnte dann definitiv ein NFS-Problem sein. - womble♦
Es gibt keine NFS-Mounts hier. Es ist die lokale Festplatte. Es ist ein sehr einfacher Linux-Server. Ein physisches Laufwerk. - Jake Wilson
strace ls /var/www/ druckt eine Menge Zeug aus. Nach was suche ich? Die letzte Zeile ist exit_group(0) = ?. - Jake Wilson
@Jakobud Versuchen strace -vf ls -l /var/www um zu sehen, ob es bei einer bestimmten Datei oder einem bestimmten Verzeichnis anhält. - ott--


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

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

Normalerweise ls würde sofort abschließen, ob die Freigabe bereitgestellt wurde oder nicht. Aber in diesem Fall hatte ich die Maschine aufgehängt und wieder in Betrieb genommen, und das Gestell funktionierte im allgemeinen schlecht. Durch das erneute Installieren der Freigabe wurde das Problem behoben.


3
2017-11-23 02:12





Ich hatte das gleiche Problem.

Das Eingeben eines Verzeichnisses ist in Ordnung, es wird aufgelistet, hängt, sucht nach Arbeiten, Tabulator beendet hängt und einige Ordner darunter tun Arbeit. Sehr Kopf kratzend-komisch.

Das Lesen dieses Threads auf Server Fault führte mich auf einen logischen Weg zur Lösung.

NAS und NAS, die normalerweise als `automount 'verwendet werden, haben mir klar gemacht, dass ich vor kurzem meine fstab auf' automount 'einige USB-Laufwerke geändert hatte, wenn sie vorhanden waren, aber weiter so normal, wenn sie nicht waren.

Ich ging dann wie folgt vor:

  1. Unmounten Sie die Partition, die das delinquente Verzeichnis enthält.
  2. Editieren Sie fstab und konvertieren Sie den gesamten Automount in entweder auskommentiert oder ohne automatisch.
  3. Laden Sie SystemD neu, wenn Sie es haben: systemctl --system daemon-reload
  4. Berg -a

Versuchen Sie, das Verzeichnis erneut einzugeben, und erhalten Sie das warme, verschwommene Gefühl, das Problem behoben zu haben.


2
2018-02-24 07:15





Womble's Vorschläge sind exzellent, und Sie sollten diese zuerst ausprobieren, aber wenn sie es nicht beheben, hatte ich dieses Problem, wenn ein Dateisystem selbstkonsistent geworden ist (durch flockige Hardware, obskure Kernel-Bugs oder sogar kosmische Strahlung).

Wenn du denkst, dass es so ist, kannst du einen fsck beim Neustart erzwingen touch /forcefsck; reboot. Beobachten Sie beim Hochfahren, was es sagt, um zu sehen, ob der fsck irgendwelche Inkonsistenzen aufnimmt.

Warnung: Dadurch werden alle Dateisysteme gefunden, die an die Maschine angeschlossen sind. tun Sie es nicht, wenn Sie auch ein Multi-Petabyte-Disk-Array angeschlossen haben, kann es dauern Tage. fsckDateisysteme können auch zu Datenverlust führen; Wenn Sie wirklich Inkonsistenzen in Ihrem Dateisystem haben, ändert e2fsck es von einem, das richtig aussieht, aber nicht ganz funktioniert, zu einem, das richtig funktioniert, aber möglicherweise nicht alles enthält, was Sie erwarten.


1
2018-03-08 06:59





Auf die Hoffnung, dass dies hilfreich sein wird, hatte ich die oben genannten Symptome durch Verwendung verursacht docker und docker compose mit dem AUFS Treiber in Ubuntu 14.04. ls <dir> war hängen, und strace ls <dir> zeigte, dass es an der getdents Anruf. Durch das Stoppen aller laufenden Container konnte ich das Laufwerk erwartungsgemäß verwenden.


0
2018-03-08 19:46





Running strace ls / var / www / wird Ihnen zeigen, was falsch ist. Ich hatte ähnliches Problem für / dir und mit strace konnte ich feststellen, dass es ein NAS-Mount war, der es verursacht hat. Das Unmounten dieses NAS hat das Problem behoben.


-2
2017-07-21 18:30



-1: Das ist nur eine Wiederholung der bereits akzeptierten Antwort. - HBruijn