パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

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

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

    • by Anonymous Coward

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

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

      • by Anonymous Coward

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

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

        • by Anonymous Coward

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

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

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

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

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

          • by Anonymous Coward

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

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

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

            • by Anonymous Coward

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

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

              • by Anonymous Coward on 2016年06月01日 16時08分 (#3022386)

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

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

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

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

                親コメント
              • by Anonymous Coward

                一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。

              • by Anonymous Coward

                ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい?

                OSはただのランチャーですか?

              • by Anonymous Coward

                > 一般的にはログイン状態を維持したままユーザーを切り替える機能があるんでGUIでもCUIでもそっちを使えばいい。

                tmux や screen での経験から考えると、それじゃ全然機能不足ですね。
                少なくとも、物理端末から切り離して、別の物理端末から利用を継続できる仕組みが必要です。

                remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。

                Windowsのように、アプリケーションとセッションが切り離し不能だってのは制限でしかないと思います。
                デフォルトでは結びついているけど明示すれば切り離しできるUNIXモデルの方がずっと柔軟だし、それでも何の問題もないのに、わざわざ柔軟性を失いたいという根拠がよく分かりませんね。

              • by Anonymous Coward

                > ユーザーから独立して動かすべき物を、普通のユーザーがボコボコ作って放置できる「だらしない」システムが正しい?

                デフォルトでは、セッション終了時に殺すべきでしょうね。
                そのための仕組みは、UNIXの最初期から存在するし、最初期からセッション終了時に殺すようになってました。
                その仕組みを使ってないGUI環境があるのは問題です。

                しかし、殺さないで残しておく仕組みも当然必要です。
                そのための仕組みが存在しないことを自慢するのは理解できませんね。

              • by Anonymous Coward

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

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

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

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

              • by Anonymous Coward

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

              • by Anonymous Coward

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

              • by Anonymous Coward

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

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

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

                これはもちろん、ジョブコントロールのマスターとなって動くシェルの

              • by Anonymous Coward

                remote desktop の場合、別ユーザーで接続しようとすると元のユーザーはログアウトくらうから機能が足りませんね。

                それはWindowsのエディションによる機能制限です。Windows Serverならデフォルトで2セッション同時に動かせます。さらに、リモートデスクトップCALを買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

処理中...