「Systemd、ログアウト時にバックグラウンドプロセスをkillするよう既定値を変更へ」記事へのコメント

本来はこっちが正しい

[Anonymous Coward]

ログアウトしたユーザーのプロセスは終了するのが本来の形。

Re:

[Anonymous Coward]

プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。

systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。

Re:

[Anonymous Coward]

> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。

どういう意味で筋が悪いのでしょうか？
SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…
まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。

Re:

[Anonymous Coward]

OS設計のあるべき姿の話でしょ。

①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿

②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿

伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。

現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。

Re:

[Anonymous Coward]

> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿

もともとUNIXはそうなってますよ。
セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。

> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
> ⇒システムからの終了シグナルを受

Re:

[Anonymous Coward]

わかってない。今回のsystemdがdeamonを殺すことについてはそのとおりだけど、元コメの「本来の姿」とはそのことを指しているわけじゃない。
そもそものUNIXの設計として、SIGHUPシグナルをプロセスが無視できて、プロセスがそれを無視すると、
あろうことかユーザーがログアウトしても残ってしまうって言うのが、OS設計のあるべき姿として問題だと指摘している。

Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。

Re:

[Anonymous Coward]

> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。

いやいや、それはありえない。
GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。
CLIのそういうプログラムなら沢山あるわけで。

実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。

あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。
囚人が檻の存在を自慢しているようにしか見えません。

Re:

[Anonymous Coward]

檻だなんだはどっちもどっちな気がするけど。

Windowsで言えばリモートデスクトップで×ボタンで閉じた状態と同じような状況をつくるためにtmuxとかscreen使ってるわけですよね(それ以外の機能もたくさんあるが、この話題で困る機能としては)。
一時中断であってログアウトしてない状況を作りたい、そのための何かがありさえすればいいんじゃないの。
ログアウトのあるべき論を話しててもしょうがないような。

Windowsでも複数セッションにまたがる…はたまにある。すごい長いインストールだとか。開発中のサーバー起動（まだサービスにする前段階）とか。なので「切断切れたら強制ログオフされるようになりました」みたいな変更は困る。Windowsでもおなじ。

# ところでtmuxとかscreenが放置されちゃってて不便みたいなことってあんまりないんですかね。

Re:

[Anonymous Coward]

なんだかよくわからないスレッドだが，SIGHUPを無視するプロセスがいなきゃ問題ないし，無視するプロセスがいるっつーんならsystemdで殺されないように勝手に動くプロセスだってすぐに出てくるだろ．なんつーか，簡単に解決できる問題をむつかしくした上に，面倒になったからブルドーザーで全部壊してるようにしか見えない．

Re:

[Anonymous Coward]

1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。
2. プロセスの死に順によっては親子関係が失われてSIGHUPは届かない。

Re:本来はこっちが正しい

[Anonymous Coward]

> 1. SIGHUPは端末の終了であって、デスクトップのセッションの終了とは別。

もともと端末の切断用だし、今でもそれが主な用途だというのは正しい。

しかし、セッションの概念および setsid(2)/getsid(2) システムコールの導入以降は、端末とは全く無関係であっても、orphaned process group に対しては、カーネルが SIGHUP を送ることが定められた。
つまり、セッションの概念の導入以降は、必ずしも端末の切断とは関係なくても、SIGHUP はセッション終了時に送られるシグナルに変わったわけ。

これはもちろん、ジョブコントロールのマスターとなって動くシェルの端末が切断された場合への対処がもともとの用途だが、SIGSTOP/SIGCONT シグナルを使ったプロセス制御は端末なしであっても有効だし実際に利用することもあるので、SIGHUP を使った安全機構を端末とは関係なしに有効にしたのは妥当な判断だったと思う。
もし端末との対応が必須であれば、セッション導入以前から存在した端末の制御プロセスの概念でほぼ同じ機能を実現できていたわけで、セッションの概念の導入自体が不要だったはず。

ただし念のため確認してみたところ、Solaris や BSD だと制御端末なしでも orphaned process group に対して SIGHUP が送られるが、Linux kernel-2.6.32 の場合は、制御端末がないと orphaned process group 扱いにならず SIGHUP が送られないようだ。
これは Linux が POSIX に違反している気がする。

POSIX の Orphapend Process Group の定義 [opengroup.org]を見ても、あるいは プロセス終了時の挙動 [opengroup.org]の
> If the exit of the process causes a process group to become orphaned,
> and if any member of the newly-orphaned process group is stopped,
> then a SIGHUP signal followed by a SIGCONT signal shall be sent
> to each process in the newly-orphaned process group.
の部分を見ても、端末に関する記述はないので。

> 2. プロセスの死に順によっては親子関係が失われてSIGHUPは届かない。

それは誤り。
プロセスグループへシグナルを送る場合には親子関係は必要ない。
たとえプロセスグループリーダーが死に、直接の親プロセスも死んで pid 1 の継子になっても、プロセスグループは変化せずにちゃんと残るようになっている。