Tôi mất nhiều thời gian trong thư mục nhỏ

Chạy Ubuntu, tôi mở một thiết bị đầu cuối và làm

sudo bash
cd /
ls | head -n 1000

Và dự đoán khoảng 20 thư mục được trả lại.

Tuy nhiên, nếu tôi làm một ls, và không đưa nó vào bất cứ thứ gì, ls chỉ treo ở đó cho đến khi tôi giết nó từ một thiết bị đầu cuối khác. Điều gì có thể xảy ra?

CHỈNH SỬA:

> type ls
ls is aliased to `ls --color=auto`

CHỈNH SỬA:

> /bin/ls /
<normal response>
> /bin/ls --color=auto
<hangs indefinitely>

Tại sao tô màu đầu ra của ls khiến lệnh này bị treo?

— Snitse
nguồn

Chạy type lsđể kiểm tra bất kỳ bí danh nào có thể, v.v.

— jw013

Chạy strace lscó khả năng giúp bạn xác định vấn đề. stracehiển thị tất cả các cuộc gọi hệ thống được thực hiện bởi chương trình mà nó gọi.

— Gowtham

Hãy thử /bin/ls(hoặc đúng hơn command ls) để chạy lsmà không có các tùy chọn bí danh, để xác nhận xem đó có phải là tùy chọn màu sắc đang tạo ra sự khác biệt hay không. FWIW, lstắt màu khi đầu ra của nó là một đường ống hoặc thiết bị không đầu cuối khác.

— jw013

một dấu gạch chéo ngược trước khi một lệnh chạy nó thay vì bí danh. \ls

— Cướp

Nếu bạn chạy ls bình thường, nó sẽ chỉ hiển thị danh sách các tệp mà không cần chạy stat (2) trên bất kỳ tệp nào. Nói cách khác, nó không tự truy cập vào PHIM mà chỉ có thư mục chứa các tệp.

Nếu bạn thêm vào tùy chọn --color hoặc sử dụng các tùy chọn ls khác cần tự kiểm tra các tệp, thì ls sẽ cần thống kê (2) các tệp đó.

Nhiều khả năng ít nhất một trong các tệp trong thư mục của bạn thực sự được gắn kết từ một hệ thống từ xa, thông qua NFS hoặc tương tự. Và máy chủ mà bạn đã gắn phân vùng đó không hoạt động hoặc không phản hồi. Vì vậy, khi ls cố gắng lấy thông tin về thư mục đó, nó sẽ bị treo trong kernel chờ máy chủ phản hồi.

Như những người khác đã đề cập, nếu bạn sử dụng strace, bạn sẽ tìm ra thư mục nào ls đang cố truy cập khi nó bị treo. Sau đó, bạn có thể umount gắn phân vùng hoặc bất cứ điều gì.

— MadSellectist
nguồn

Một khả năng khác là một trong các tệp trong thư mục của bạn là một liên kết tượng trưng chỉ đến một số phân vùng ở xa và máy chủ của họ không đáp ứng ... cùng một nguyên tắc.

— MadSellectist

Tôi đã có nfs gắn kết từ một máy chủ bị sập. Có vẻ kỳ lạ là stat chỉ bị treo trên nfs mount. Sẽ không quá khó để nói nếu nó bị hỏng và chỉ in thư mục màu mà các liên kết tượng trưng bị hỏng được in.

— Snitse

Trên thực tế, thật khó (đối với ls) để nói rằng máy chủ NFS không hoạt động. NFS chỉ là một loại hệ thống tệp khác nhau (như ext3, xfs, v.v.) Tất cả các hệ thống tệp được triển khai trong kernel. Một chương trình người dùng như ls (1) chỉ cần chạy một cuộc gọi hệ thống như stat (2) trên tên đường dẫn; nó không biết loại hệ thống tập tin nào đang được sử dụng. Trong trường hợp này, cuộc gọi hệ thống bị treo (vì vậy ứng dụng không gian người dùng bị treo) cho đến khi có kết quả. Vì vậy, ls được đưa vào trạng thái ngủ cho đến khi kết quả thu được ... điều đó không bao giờ xảy ra. Vì vậy, tôi không thể nói điều gì đó là sai.

— MadSellectist

Tôi nên nói rằng bạn CÓ THỂ thay đổi hành vi của NFS. Nếu bạn chỉ định "gắn kết cứng", thì kernel sẽ cố gắng kết nối lại mãi mãi nếu máy chủ hết thời gian và sẽ không quay lại từ cuộc gọi hệ thống cho đến khi điều đó xảy ra. Ngoài ra, bạn có thể yêu cầu "mount mềm", trong đó kernel trả về lỗi nếu máy chủ yêu cầu hết thời gian. Tuy nhiên, nhiều / hầu hết các chương trình không được viết để xử lý đúng các loại hoạt động hết thời gian này và do đó, việc chỉ định các giá treo mềm trong NFS là nguy hiểm và gây mất ổn định hệ thống. Những người sử dụng NFS thường xuyên hầu như luôn luôn sử dụng và đề nghị gắn kết cứng. Xem nfs (5).

— MadSellectist

Tôi đã có thú sshfscưỡi, và cách duy nhất tôi có thể tháo gỡ chúng là giết chết các quy trình sshvà liên quan sshfs.

— Gauthier