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

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

  • by Anonymous Coward on 2016年05月31日 20時48分 (#3021973)

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

    • by Anonymous Coward on 2016年05月31日 20時57分 (#3021988)

      その昔UNIXマシンを多数のユーザで共有していた頃は、
      「バックグラウンドでプログラムを動かしたままログアウトするな!リソース不足になるだろ!」
      ってよく怒られたものでした・・・

      親コメント
    • by Anonymous Coward on 2016年06月01日 10時55分 (#3022219)

      いやいや、今回の件では、daemon(3) 呼んだプロセスまで殺されるんですよ。
      デーモンプロセスは、ユーザー起動であっても、本来は殺されない方が筋。

      こういう非互換な変更を平気で入れてくるってことは、systemdのメンテナーは、従来から存在するプログラムとの互換性は気にしないってポリシーなんでしょうね。
      今後も同様な問題がたびたび起きそうな予感。

      親コメント
      • by Anonymous Coward

        伝統的なinit(8)の代わりとして十分モダンで効率的で、かつsystemdのようにシステム全体をLinux cgroup(3)に過度に依存させるようなことを無神経に強要させない、穏やかな設計・実装方針のものが主流に置き換わって欲しい

    • by Anonymous Coward

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

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

      • by Anonymous Coward

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

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

        • by Anonymous Coward

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

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

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

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

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

          • by Anonymous Coward on 2016年06月01日 15時13分 (#3022353)

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

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

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

            これも当然ですね。
            そのためにSIGHUPシグナルが定義されてます。

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

            伝統的なUNIXというよりは、GUIユーザー環境が、行儀が悪くできているというのが正しい表現だと思います。
            本来なら、GUIユーザー環境のセッションマネージャは、配下のプロセスが、セッション終了時にSIGHUPシグナルを受け取るように手配すべきでしょう。これは、setsid(2) したプロセスがGUIユーザー環境のプロセスを起動するようにするだけで済むので簡単なことです。
            そうせずに、daemon(3) API を呼んでデーモン化したプロセスまで殺すような変更をするから、今回、非難を受けているわけです。

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

            伝統的UNIXのやり方を知らないのは、はたしてどちらの側なのでしょうか…

            親コメント
            • 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

                じゃあ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を買って、機能を有効化すれば、ライセンスの許す限りいくつでもセッションを作れるようになります。

    • by Anonymous Coward

      Windowsは普通にそうなってるよな。必要ならmachine-wideなサービスを作れっていうスタンス。
      systemdもそれを目標としてるんだろう。古参連中が理解できないだけで。

      • by Anonymous Coward

        新しい酒は新しい革袋に。systemd-compatibleなユーザランドだけに浄化した新しいディストロでやってくれ。
        Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?

        • by uxi (5376) on 2016年06月02日 18時31分 (#3023190)

          Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?

          よ、呼んだ?

          --
          uxi
          親コメント
        • by Anonymous Coward

          多分、付けた方がいい。

          • by Anonymous Coward

            > 多分、付けた方がいい。

            いったいどういう利点があるんでしょう?

            ちなみに欠点はすごく沢山あります。
            一番ヤバいのは、プロセス起動するソフトウェアを全部書き換える必要が生じるところですね。
            今回の systemd とは比べ物にならないくらい悲惨に、互換性が壊滅します。

            • by uxi (5376) on 2016年06月02日 18時37分 (#3023194)

              Cygwin の場合、
              現実問題として、.exe 付いてても大してメリットはない気がするんだけど、
              逆に .exe 付いてるからと言って大してデメリットが生じてるわけでもないよ。

              間に噛んでる Cygwin 層の
              システムコールが面倒見てくれるから
              ユーザーが書くプログラムでは
              .exe 付いてることを意識しなければいけない場面はほとんどないしね。

              --
              uxi
              親コメント
              • by Anonymous Coward

                いや cygwin は Linux じゃないから、「cygwin ではデメリットない」て話はオフトピックですよ。
                Linux じゃシステムコール層がそういう面倒みてくれないし。

                それにメリット説明してないし。

              • by uxi (5376) on 2016年06月02日 19時36分 (#3023235)

                そうは読めなかったなぁ。

                Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?

                って書いてあったから、てっきり Windows の /bin その他の話かと。

                Cygwin でのメリットは、explorer から見たときに実行ファイルだって分かり易いとか、cmd や explorer から実行できるとかその辺かな?
                そういう使い方はあまりしないので、大したメリットではないけど、最低限 mintty とか bash とかは .exe 付いてないと使えない気がする。

                --
                uxi
                親コメント
            • by Anonymous Coward

              まず、ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。

              そもそも、Unixのデスクトップだって、.txtみたいな拡張子を導入して、拡張子が.txtだったらgeditで開いて、.htmlだったらfirefoxで開く、ということをごく当たり前にやってる。makeだって、拡張子の.oとか.cとか.soとかに依存した文化がある。実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一端書き換えたら、全体的な複雑さは減る。

              • by Anonymous Coward

                > ファイルが実行可能かどうかはどこかに情報を書き込まなければゴミになる。ファイル名に書く必要はないがファイル名に書くのは互換性の点で優れている。

                Windowsとの互換性に優れているという意味なのでしょうか?
                でも、今や計算機の数ではiPhoneやAndroidの方が圧倒的に多いわけで、
                iPhoneやAndroidはLinuxと同様に、ファイルシステム自身に実行形式属性を記録して持っているわけです。
                むしろWindowsがiPhone/Android/MacOS/Linuxと同じ方法に変更した方が、
                互換性において圧倒的に優れているでしょう。

                > 実行ファイルにだけ拡張子をつけないのは悪しき慣例だよ。一

    • by Anonymous Coward

      プログラムで言うと○○リークとおなじですからね。
      今までが異常でUnixの嫌いなとこの1つでした。

      initスクリプトもI/Fシカトが多くてイヤだったけどね。
      このあたりが組織ごとにバラバラ独自ルール、時によっては真逆の方針生んでたり、バカじゃね?と思ったもんです。

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...