アカウント名:
パスワード:
ログアウトしたユーザーのプロセスは終了するのが本来の形。
プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。
> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
どういう意味で筋が悪いのでしょうか？SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。
OS設計のあるべき姿の話でしょ。
①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
もともとUNIXはそうなってますよ。セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。
> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき> ⇒システムからの終了シグナルを受
わかってない。今回のsystemdがdeamonを殺すことについてはそのとおりだけど、元コメの「本来の姿」とはそのことを指しているわけじゃない。そもそものUNIXの設計として、SIGHUPシグナルをプロセスが無視できて、プロセスがそれを無視すると、あろうことかユーザーがログアウトしても残ってしまうって言うのが、OS設計のあるべき姿として問題だと指摘している。
Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
いやいや、それはありえない。GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。CLIのそういうプログラムなら沢山あるわけで。
実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。
あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。囚人が檻の存在を自慢しているようにしか見えません。
一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
> 一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
tmux や screen での経験から考えると、それじゃ全然機能不足ですね。少なくとも、物理端末から切り離して、別の物理端末から利用を継続できる仕組みが必要です。
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
Windowsのように、アプリケーションとセッションが切り離し不能だってのは制限でしかないと思います。デフォルトでは結びついているけど明示すれば切り離しできるUNIXモデルの方がずっと柔軟だし、それでも何の問題もないのに、わざわざ柔軟性を失いたいという根拠がよく分かりませんね。
それはWindowsのエディションによる機能制限です。Windows Serverならデフォルトで2セッション同時に動かせます。さらに、リモートデスクトップCALを買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
本来はこっちが正しい (スコア:0)
ログアウトしたユーザーのプロセスは終了するのが本来の形。
Re: (スコア:0)
プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。
Re: (スコア:0)
> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
どういう意味で筋が悪いのでしょうか？
SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…
まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。
Re: (スコア:0)
OS設計のあるべき姿の話でしょ。
①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
Re: (スコア:1)
> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
もともとUNIXはそうなってますよ。
セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。
> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
> ⇒システムからの終了シグナルを受
Re: (スコア:0)
わかってない。今回のsystemdがdeamonを殺すことについてはそのとおりだけど、元コメの「本来の姿」とはそのことを指しているわけじゃない。
そもそものUNIXの設計として、SIGHUPシグナルをプロセスが無視できて、プロセスがそれを無視すると、
あろうことかユーザーがログアウトしても残ってしまうって言うのが、OS設計のあるべき姿として問題だと指摘している。
Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
Re: (スコア:1)
> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
いやいや、それはありえない。
GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。
CLIのそういうプログラムなら沢山あるわけで。
実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。
あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。
囚人が檻の存在を自慢しているようにしか見えません。
Re:本来はこっちが正しい (スコア:0)
一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
Re: (スコア:0)
> 一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。
tmux や screen での経験から考えると、それじゃ全然機能不足ですね。
少なくとも、物理端末から切り離して、別の物理端末から利用を継続できる仕組みが必要です。
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
Windowsのように、アプリケーションとセッションが切り離し不能だってのは制限でしかないと思います。
デフォルトでは結びついているけど明示すれば切り離しできるUNIXモデルの方がずっと柔軟だし、それでも何の問題もないのに、わざわざ柔軟性を失いたいという根拠がよく分かりませんね。
Re: (スコア:0)
remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。
それはWindowsのエディションによる機能制限です。Windows Serverならデフォルトで2セッション同時に動かせます。さらに、リモートデスクトップCALを買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。