Các chương trình chạy từ một phiên ssh phụ thuộc vào kết nối?


29

Có một chương trình được chạy từ một phiên ssh phụ thuộc vào kết nối đến máy khách không? Ví dụ khi kết nối thực sự chậm. Vì vậy, nó có chủ động chờ đợi cho đến khi mọi thứ được in trên màn hình?

Và nếu nó phụ thuộc vào kết nối, thì nó cũng xảy ra với màn hình hay byobu chẳng hạn? Vì với các chương trình này được duy trì chạy ngay cả sau khi ngắt kết nối với máy chủ.


Lưu ý: Tôi chỉ tìm thấy những câu hỏi liên quan:


1
Lưu ý rằng nếu kết nối của bạn bị mất, chương trình sẽ tiếp tục chạy cho đến khi hết thời gian phiên (trừ khi bị kẹt trong thao tác in), nhưng nếu phiên của bạn kết thúc, chương trình sẽ bị chấm dứt một cách duyên dáng.
17:00

Câu trả lời:


26

Đầu ra của các chương trình được đệm, vì vậy nếu kết nối chậm, chương trình sẽ bị dừng nếu bộ đệm đầy.

Nếu bạn sử dụng screen, nó cũng có một bộ đệm mà nó sử dụng để thử và hiển thị cho một phiên được kết nối. Nhưng một chương trình được kết nối trong phiên màn hình sẽ không bị dừng nếu screenkhông thể cập nhật thiết bị đầu cuối từ xa đủ nhanh. Giống như khi mất kết nối, chương trình tiếp tục điền vào screensbộ đệm cho đến khi tràn ra (đẩy ra thông tin cũ nhất). Những gì bạn thấy đến (và có thể cuộn trở lại) là tùy thuộc vào những gì (vẫn) trong bộ đệm đó. screenngăn cách hiệu quả chương trình của bạn khỏi thiết bị đầu cuối của bạn (và kết nối SSH chậm của bạn).


9

Kết nối SSH có thể chết sớm nếu kết nối TCP bên dưới nhận được gói có cờ RST . Điều đó có thể xảy ra nếu một bên gửi một gói (có thể là đầu dò giữ SSH định kỳ) nhưng không nhận được xác nhận TCP trong một khoảng thời gian hợp lý hoặc nếu bộ định tuyến quyết định rằng kết nối không hoạt động quá lâu hoặc nếu một ISP chỉ là xấu xa.

Trong mô hình thiết bị đầu cuối Unix, khi kết nối thiết bị đầu cuối bị hủy, trình điều khiển thiết bị đầu cuối sẽ gửi tín hiệu HUP đến trình bao, việc chấm dứt cũng khiến SIGHUP được gửi đến các tiến trình đang chạy trong trình bao.

Từ Câu hỏi thường gặp về lập trình viên Unix , mục 1.15:

SIGHUPlà một tín hiệu có nghĩa là, theo quy ước, "đường dây cuối bị treo". Nó không liên quan gì đến các tiến trình cha và thường được tạo bởi trình điều khiển tty (và được gửi đến nhóm quy trình nền trước).

Tuy nhiên, là một phần của hệ thống quản lý phiên, có chính xác hai trường hợp SIGHUPđược gửi về cái chết của một quy trình:

  • Khi quy trình chết là người lãnh đạo phiên của phiên được gắn vào thiết bị đầu cuối, SIGHUPđược gửi đến tất cả các quy trình trong nhóm quy trình tiền cảnh của thiết bị đầu cuối đó.

  • Khi cái chết của một quá trình làm cho một nhóm quá trình trở thành mồ côi, và một hoặc nhiều quá trình trong nhóm mồ côi bị dừng lại , SIGHUPvà sau đó SIGCONTđược gửi đến tất cả các thành viên của nhóm mồ côi. (Một nhóm quy trình mồ côi là một nhóm trong đó không có quy trình nào trong nhóm có cha mẹ là một phần của cùng một phiên, nhưng không phải là cùng một nhóm quy trình.)

Trình xử lý tín hiệu mặc định cho SIGHUP là chấm dứt quá trình:

Signal     Value     Action   Comment
----------------------------------------------------------------------
SIGHUP        1       Term    Hangup detected on controlling terminal
                              or death of controlling process

Có thể tránh kết thúc quá trình, mặc dù.

  • Bạn có thể chèn một trình xử lý tín hiệu mà bỏ qua SIGHUP. Để làm điều đó như một người dùng, bọc lệnh nohup. Ví dụ:

    nohup make all &
    
  • Bạn có thể nói với vỏ để phân tách một quá trình con từ nó. Ví dụ, Bash có một disownlệnh tích hợp:

    make all
    

    CtrlZ

    bg
    disown %1
    

    Sau đó, SIGHUP sẽ không được truyền cho trẻ (không còn là trẻ em).

  • Một số chương trình, đặc biệt là trình nền , sẽ tự động sử dụng các cơ chế ở trên: chương trình có thể cài đặt trình xử lý SIGHUP thay thế (sử dụng sigaction(2)) hoặc có thể chọn tham gia phiên mới ( setsid(2)).
  • Bạn có thể chạy screenhoặc tmuxphân bổ giả TTY để chạy phiên có vỏ không nhận SIGHUP khi kết nối SSH chết. SIGHUP không được chuyển tiếp từ phiên SSH sang phiên màn hình / tmux.

Ngẫu nhiên, một cách khác để xử lý các kết nối SSH không đáng tin cậy là sử dụng giao thức Mosh thay thế. Mosh chạy trên UDP, do đó không có kết nối TCP nào có nguy cơ bị đặt lại.



1

Có, một chương trình chạy qua SSH sẽ phụ thuộc vào đầu ra của nó đi đâu đó. Nếu kết nối chậm, đầu ra phải được đệm ở đâu đó và bộ đệm không thể là vô hạn, vì vậy chương trình phải chặn nếu chúng được lấp đầy.

Lưu ý rằng đầu ra có thể không nhất thiết phải đến một thiết bị đầu cuối: xem xét việc chạy một cái gì đó như

ssh user@somewhere "cat file.txt" > file.txt

Điều này sẽ có hiệu lực sao chép các tập tin. Để làm việc này, tốc độ đầu ra của mèo phải khớp với kết nối: rõ ràng là việc mất các phần của đầu ra từ giữa sẽ không được chấp nhận.

Màn hình sẽ thay đổi tình huống trong đó nó hoạt động như một thiết bị đầu cuối và sẽ lưu những gì sẽ được hiển thị "trên cửa sổ thiết bị đầu cuối" (cộng với cuộn ngược lại). Không cần phải nhớ tất cả mọi thứ mà chương trình của bạn xuất ra, chỉ những phần phù hợp với "cửa sổ" và cuộn lại. Theo mặc định, màn hình sẽ chờ kết nối chậm (chặn chương trình), nhưng nó có thể được cấu hình để phát hiện kết nối bị kẹt bằng cách đặt "không chặn".

Từ trang người đàn ông:

không chặn [bật | tắt | numsecs]

Cho màn hình biết cách xử lý giao diện người dùng (màn hình) ngừng chấp nhận đầu ra. Điều này có thể xảy ra nếu người dùng nhấn ^ S hoặc kết nối TCP / modem bị cắt nhưng không nhận được hangout. Nếu nonblock bị tắt (đây là mặc định), màn hình sẽ đợi cho đến khi màn hình khởi động lại để chấp nhận đầu ra. Nếu không chặn được bật, màn hình sẽ đợi cho đến khi hết thời gian chờ (bật được coi là 1s). Nếu màn hình vẫn không nhận được ký tự, màn hình sẽ coi nó là "bị chặn" và ngừng gửi các ký tự đến nó. Nếu đôi khi nó khởi động lại để chấp nhận các ký tự, màn hình sẽ bỏ chặn màn hình và hiển thị lại nội dung cửa sổ được cập nhật.

Ngắt kết nối khác với kết nối chậm. Plain SSH không thể tự động phục hồi từ nó, vì vậy chương trình của bạn sẽ nhận được SIGHUP. Mặt khác, màn hình sẽ phát hiện ngắt kết nối, tách ra và quay trở lại bộ đệm cục bộ cho đến khi màn hình được gắn lại. Điều này sẽ không chặn chương trình đang chạy.

(Thiết lập nonblock 1trong bạn .screenrclà rất quan trọng nếu bạn chạy một cái gì đó giống như irssi mà liên tục sẽ tạo ra sản lượng nhưng vẫn phải nói chuyện với mạng cùng một lúc. Blocking sẽ dẫn đến bị ngắt kết nối từ IRC, mà là cực kỳ khó chịu ...)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.