Nếu tôi khởi chạy một quá trình nền và sau đó đăng xuất, nó sẽ tiếp tục chạy chứ?


29

Hỏi điều này sau một cuộc thảo luận kéo dài với đồng nghiệp, tôi thực sự muốn làm rõ ở đây.

Tôi khởi chạy một quá trình nền, bằng cách thêm " &" vào dòng lệnh hoặc bằng cách dừng nó CTRL-Zlại và tiếp tục nó ở chế độ nền với " bg". Sau đó tôi đăng xuất.

Chuyện gì xảy ra

Chúng tôi khá chắc chắn rằng nó đáng lẽ đã bị SIGHUP giết, nhưng điều này đã không xảy ra; khi đăng nhập lại, quá trình này đang diễn ra một cách vui vẻ và pstreecho thấy nó đã được "thông qua" bởi init.

Đây có phải là hành vi dự kiến?

Nhưng sau đó, nếu có, nohupmục đích của lệnh là gì? Dường như quá trình sẽ không bị giết dù thế nào, có hoặc không có nó ...


Chỉnh sửa 1

Một số chi tiết:

  • Lệnh được khởi chạy từ phiên SSH, không phải từ bảng điều khiển vật lý.
  • Lệnh được đưa ra mà không có nohup và / hoặc &; sau đó nó đã bị đình chỉ CTRL-Zvà tiếp tục trong nền với bg.
  • Phiên ssh không giảm. Có một đăng xuất thực tế ( exitlệnh "").
  • Quá trình này là một scphoạt động sao chép tập tin.
  • Khi đăng nhập lại, pstreecho thấy quá trình chạy và là con của init.

Chỉnh sửa 2

Để nêu câu hỏi rõ ràng hơn: sẽ đặt một quá trình trong nền (sử dụng &hoặc bg) làm cho nó bỏ qua SIGHUP, giống như nohuplệnh nào?


Chỉnh sửa 3

Tôi đã thử gửi thủ công SIGHUPđến scp: nó đã thoát, vì vậy nó chắc chắn không bỏ qua tín hiệu.

Sau đó, tôi đã thử khởi chạy lại nó, đặt nó vào nền và đăng xuất: nó đã được "thông qua" initvà tiếp tục chạy, và tôi đã tìm thấy nó ở đó khi đăng nhập lại.

Bây giờ tôi khá bối rối. Có vẻ như không SIGHUPđược gửi ở tất cả upong đăng xuất.


Tôi không thấy bất kỳ đề cập nào về I / O của bàn điều khiển trong đó, điều này cũng sẽ làm mọi thứ tăng lên. Bạn đã chuyển hướng những thứ tức là 1>/dev/null 2>&1cho bash, vv?
Avery Payne

Không, tôi đã không. SCP tất nhiên không yêu cầu đầu vào tiêu chuẩn ... và đầu ra tiêu chuẩn dường như không phải là một vấn đề.
Massimo

Việc shell của bạn có được thực thi như một shell đăng nhập thay đổi hiệu suất hay không, đó có thể là trường hợp ở đây.
Warner

Thực hiện một số thử nghiệm khác; Tôi đã tóm tắt nó ở đây: serverfault.com/questions/117152 .
Massimo

Câu trả lời:


20

Trả lời tìm thấy.

Đối với BASH, điều này phụ thuộc vào huponexittùy chọn shell, có thể được xem và / hoặc thiết lập bằng cách sử dụng shoptlệnh tích hợp.

Có vẻ như các tùy chọn này được tắt theo mặc định, ít nhất là trên các hệ thống dựa trên RedHat.

Thông tin thêm trên trang người đàn ông BASH :

Shell thoát theo mặc định khi nhận được SIGHUP. Trước khi thoát, một vỏ tương tác gửi lại SIGHUP cho tất cả các công việc, đang chạy hoặc dừng. Các công việc đã dừng được gửi SIGCONT để đảm bảo rằng họ nhận được SIGHUP. Để ngăn vỏ gửi tín hiệu đến một công việc cụ thể, cần loại bỏ nó khỏi bảng công việc với phần dựng sẵn (xem SHELL BUILTIN THÔNG TIN bên dưới) hoặc được đánh dấu để không nhận SIGHUP bằng cách sử dụng từ chối -h.

Nếu tùy chọn shell huponexit đã được đặt với shopt, bash sẽ gửi SIGHUP cho tất cả các công việc khi thoát khỏi vỏ đăng nhập tương tác.


2
Đó là một mặc định ngu ngốc, nhưng can đảm của tôi nói với tôi rằng đó là lỗi của RH chứ không phải là bash. Btw, với zsh bạn có thể sử dụng &! như một lối tắt để từ chối, và các quá trình rẽ nhánh với & làm cho thở dài.
Jürgen Strobel

7

Tôi đồng ý với Warner và chỉ muốn thêm rằng bạn có thể ngăn shell gửi SIGHUP bằng lệnh "disown" dựng sẵn. Trang bash man chứa một mô tả hay.


4

Bạn có thể sử dụng lệnh nohup để khởi chạy lệnh và chuyển hướng đầu ra thành tệp đầu ra nohup. Từ trang người đàn ông nohup:

nohup - run a command immune to hangups, with output to a non-tty

Tùy chọn khác là sử dụng lệnh màn hình . Lợi ích của việc sử dụng màn hình là bạn có thể kết nối lại với quy trình sau.


Tại sao các downvote? Sử dụng nohup và màn hình là những cách hoàn toàn chấp nhận được để tránh làm mất quá trình đăng xuất. Có những người khác, nhưng cả hai công việc này. Thỏa thuận là gì?
Jim

2
Tôi nghĩ đó là một điểm tuyệt vời, nhưng Q là về lý do tại sao các quy trình của anh ta không bị giết KHÔNG "làm thế nào để giữ cho chúng khỏi bị giết".
CarpeNoctem

2

Khi bạn rẽ một tiến trình vào nền, nó vẫn sẽ là tiến trình con từ trình bao thực thi nó.

Tất cả các tiến trình con chạy dưới vỏ được gửi SIGHUP khi thoát. Hiệu suất thay đổi một chút tùy thuộc vào tình huống chính xác, được nêu chi tiết rõ ràng trong trang của bash. Các vỏ khác có thể có mô tả tương tự.

Apache và các trình tiện ích khác, thường tải lại cấu hình trên SIGHUP. Tiện ích không gian người dùng thường chết. Hiệu suất ứng dụng được liên kết với các tín hiệu có thể là duy nhất cho ứng dụng.


Vì vậy, quá trình nên đã nhận được một SIGHUP trong trường hợp này, phải không? Có lẽ nó chỉ bỏ qua nó, tôi sẽ kiểm tra.
Massimo

Đúng chính xác. Đó là những gì tôi tin rằng tình hình sẽ được. Nếu bạn thực sự nghi ngờ về hiệu suất được ghi lại, bạn có thể hack một đoạn script nhỏ để bẫy tín hiệu và ghi lại nó.
Warner

0

Quá trình là gì? Hiệu suất được mô tả trong bài 1 trước đó là chính xác.

Một số chức năng và quy trình kịch bản có thể bẫy tín hiệu. trong khi các vòng lặp có thể chạy trốn như điên.

Xem:

Phiên SSH giảm - Lệnh có tiếp tục thực thi không?

Chỉnh sửa 1 lúc 4:22 chiều

Từ trang bash:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

Nghiên cứu ban đầu 1 cho thấy OpenSSH có thể bỏ qua SIGHUP, có thể nhiều tín hiệu hơn.


Bài đăng đó thực sự khiến tôi phải đặt câu hỏi. Để biết chi tiết, xem chỉnh sửa ở trên.
Massimo

2
Các câu trả lời trong luồng khác làm cho nó nghe giống như bạn cần đọc lệnh SCP mà bạn đang sử dụng và xem cách nó phản hồi với SIGHUP
mfinni

Và 'nohup' dành cho các lệnh mà bạn biết sẽ chết với SIGHUP và bạn không muốn chúng, tôi đoán vậy.
mfinni

Trang người đàn ông không nói điều đó; Tôi sẽ thử giết nó -HUP vào ngày mai ...
Massimo

-1

Nếu bạn không khởi chạy lệnh thông qua một công cụ như thế screen, thì khi phiên kết thúc, thì tất cả các công việc / nhiệm vụ liên quan đến phiên đó cũng vậy.


Đó chính xác là những gì tôi đã nghĩ, ngoại trừ ... họ chỉ không làm thế.
Massimo

họ có mỗi lần tôi thực hiện những gì bạn mô tả ... có lẽ nó phụ thuộc vào vỏ bạn sử dụng?
warren

-1 Họ không; Câu trả lời không đơn giản như vậy. Tôi chỉ thử nghiệm một kịch bản shell đơn giản mà tôi đã bắt đầu trong nền; nó lặp và gửi đầu ra đến một tập tin tạm thời. Nó tiếp tục chạy sau khi tôi thoát khỏi thiết bị đầu cuối (như được thấy bởi tail -ftệp tạm thời. Cái này trên máy CentOS 7.1 sử dụng bash.
Mike S

@MikeS - hãy chứng minh. Tôi chưa bao giờ chứng kiến ​​hành vi mà bạn mô tả
warren

@warren - Xem câu trả lời của tôi cho serverfault.com/questions/117152/ . Lưu ý rằng một số người yêu cầu hành vi khác với những gì bạn mô tả; Thật vậy, Massimo đã đăng chính xác vì quá trình của anh ấy tiếp tục.
Mike S
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.