Systemd、ログアウト時にバックグラウンドプロセスをkillするよう既定値を変更へ 82
ストーリー by hylom
知らずに悲劇が発生する予感 部門より
知らずに悲劇が発生する予感 部門より
Ryo.F 曰く、
Debianのバグトラッカによると、/etc/systemd/logind.confで設定できる「KillUserProcesses」の既定値が「no」から「yes」に変更されたようだ（Slashdot）。
たとえばsshで接続してscreenやtmuxで作業し、デタッチ・ログアウトしてしばらく経ってから作業結果を確認、といった作業で悲劇が起こる可能性が。
なぜこうなった……。
KillUserProcessesの値が「yes」に設定されていると、ログアウト時にsystemdが自動的にユーザーのバックグラウンドプロセスを削除するようになる。それによってこのような問題が発生するようになるという。
systemd「私がルールブックです」 (スコア:3, おもしろおかしい)
例えば、sshで接続して、screenやtmuxで作業して、デタッチ・ログアウトして、しばらく経ってから作業結果を確認…とかで悲劇が起こる可能性が。
これから先、screenやtmux使う時には、忘れずにsystemd-run --scope --userって前置詞つけて起動しろってことだよ。
ログアウト後に殺さないで貰えるかどうかを管理者たるsystemd様にお伺いたてとけってこった。言わせんな恥ずかしい。
// やりたい放題やってんな >>>systemd
// もはやOOM Killerよりたち悪い
Re: (スコア:0)
nohupの立場はどうなるんです？全てのシェルはsystemd対応せよってことなんですかい？
変更には理由あり (スコア:2, すばらしい洞察)
リンク先にも書いてありますが、そもそもはGNOMEだとログアウト時にgnome-keyringとかのプロセスが残ってしまい、ログインログアウトを連発するとゾンビ化したプロセスが多発することが理由のようです。
https://bbs.archlinux.org/viewtopic.php?id=204307 [archlinux.org]
https://bugs.freedesktop.org/show_bug.cgi?id=94508 [freedesktop.org]
黙って変更したわけじゃないんだからこっちで対応すりゃいいだけの話じゃん、と気にならないのは少数派なのか。
Re:変更には理由あり (スコア:3, すばらしい洞察)
慣例に従って書かれた今までのコードすべてとの互換性を壊してしまうような変更だから問題になるのでしょう。
http://www.glamenv-septzen.net/view/854#idf2f03a [glamenv-septzen.net]
setsid、signal まわりで対応していた世界に
「PAMで新規セッションを作成しろ」というのは筋が悪いと思います。
X のログインと TTY のログインがかけ離れているのに、同じ枠組みで取り扱ってきたのが問題のような気もします。
# mishimaは本田透先生を熱烈に応援しています
Re:変更には理由あり (スコア:1)
同意。
慣例じゃなくて仕組みかな。
CUIなら PID, PPID, PGID, SID, TPGID, tty あたりがあれば一通り問題なく動くからねぇ…。
ただ、これらのIDは擬似端末とプロセスと標準入出力に紐づいた仕組みで、
GUI(desktop session) を管理するには足りないのは分かるが
GUI用の仕組みを作るのが筋であって、巻き添えにするのは違う。
[Q][W][E][R][T][Y]
Re:変更には理由あり (スコア:1)
セキュリティ、オーディオ、文字入力、クラウドサービス等でユーザー単位のデーモンを作る時って、logout時に正しく終了させるというのは結構難しいんですよね。知らない間にorphanになってて、それを検出する良い方法も無いですし。
systemdは同じsessionに属するプロセスをorphanでも追いかけれるんでlogout時にclean upできるのはありがたいですが、普通にやっちゃうと互換性が無くて怒る人たちが多いようです。いっそのことorphan processにもSIGHUPを送れば良いんじゃねと思ったりしますが変ですかね？(理想的にはsignalの新設なんかも)
Re: (スコア:0)
> セキュリティ、オーディオ、文字入力、クラウドサービス等でユーザー単位のデーモンを作る時って、logout時に正しく終了させるというのは結構難しいんですよね。知らない間にorphanになってて、それを検出する良い方法も無いですし。
本物のデーモンなら難しいですが、GNOME 関係ならユーザーとの対話を伴うようなプログラムでしょうし、
単にユーザーセッションに対応するプロセスグループを作ってそれに属させておいて、ログアウト時に、
SIGHUP をプロセスグループに送ればいいと思うんですが、それでなにか問題があるのでしょうか？
Re: (スコア:0)
そのようにしないプログラマが多すぎるからゾンビが残っちゃうんでしょ。
Re:変更には理由あり (スコア:1)
> リンク先にも書いてありますが、そもそもはGNOMEだとログアウト時にgnome-keyringとかのプロセスが残ってしまい、ログインログアウトを連発するとゾンビ化したプロセスが多発することが理由のようです。
要はGNOMEのバグがとれないから、GNOMEを直すんじゃなくて、従来から存在する大量のプログラムに対して、非互換な変更を押し付けるってこと？
> 黙って変更したわけじゃないんだからこっちで対応すりゃいいだけの話じゃん、と気にならないのは少数派なのか。
基盤ソフトウェアを保守する立場からすると、ありえないですね。
基盤的なソフトウェアの場合、従来からその基盤に依存しているアプリケーションとの互換性を維持するというのは、普通なら相当に優先度が高い目標です。
バグを直すんじゃなくて、互換性を壊して誤魔化すとか、ありえない選択かと。
正常な判断力があれば、バグを直すことで対応するのでは？
Re: (スコア:0)
GNOMEをkillしちゃえよもう
なんでGNOMEの問題に他が巻き込まれにゃんらんのだ
Re: (スコア:0)
Systemd使うの諦めれば済むだろ。
Re: (スコア:0)
脈絡のないものを並べるとか
批判と戦いたいだけにしか見えないな。
Re: (スコア:0)
改「善」と言う辺り有用性は認めているから
そういった「意見が参考にならない人間」がどういった思考しているのか、もう少し詳しく教えて
Re:変更には理由あり (スコア:1)
いや、普通にそうでしょ？
頑固に7だの8.1だの使い続けても面倒なだけじゃん
メジャーな製品を使う時は、長いものに巻かれとくのが正解。
Re: (スコア:0)
アプリってのはWordとExcelとPowerPointのことなんだよ、
普通の人間にとってはね。
Re:変更には理由あり (スコア:2)
そのアプリにsystemdが加わる流れか
敢えて言おう。カスである！と。
もうやだ勘弁して (スコア:1)
systemdってCLIでPC操作すること全く考慮してないよね
不便になっていく一方
Re:もうやだ勘弁して (スコア:1)
私を含む、Linuxをサーバー or CUI環境 (sshログインして計算ぶん回すとか) だけで使うことにしか興味ない人って、Linuxデスクトップ環境で生活している人よりも多いんじゃないかと思うがどうだろう？
Webブラウジングや文書書き、コーディングとテストまでは手元のMacで、サーバーとしてのデプロイ先や計算機資源としてLinuxをリモートで使用、というような。
そういう人にとって、GNOMEやらfreedesktop.orgのゴミやら何やら全く興味ないし、今まで使っているtmuxやscreenがなんでそんなくだらんモノのとばっちり受けなきゃいけないんだと溜息つきたくもなりますね。
Re: (スコア:0)
LinuxがWindowsやMacと違って一般受けしない理由がよくわかるわ
Re: (スコア:0)
iいわゆるLinuxデスクトップ環境なんか一般受けしなくていいじゃないか
それは、強いて言えばAndroidの役目
そんなんのが無くても、サーバーや科学技術計算の世界で主役級の存在価値を持つLinuxなんだから、そっちの邪魔になる変更を、全プロセスの親という重要な所に無神経に入れないで欲しい
Re: (スコア:0)
> サーバーや科学技術計算の世界で主役級の存在価値を持つLinuxなんだから
スパコンでは、Linuxが圧倒的なシェアを持つわけですが（2015年11月の時点で、Top500 の98.8%がLinux）、
スパコンでこの機能有効にしたら、ユーザー起動のバッチジョブが全部殺されてとんでもないことになりそうですね…
Re: (スコア:0)
KillUserProcesses=no で納入しろよ。
Re:もうやだ勘弁して (スコア:1)
> KillUserProcesses=no で納入しろよ。
スパコンとして納入されてるマシンなら、当然そうするでしょうけど、
手元のLinux PCでプログラムを開発して、計算規模を大きくする段階で
スパコンを利用するのが普通だから、各研究者が持つLinux PCで、
KillUserProcessesを no に変更することが強いられるわけですな。
スパコン使う研究者じゃなくても、Linuxで動くサーバーソフトウェアを
開発しているプログラマーにも同じ問題があるでしょうね。
実は、今Linuxをデスクトップで利用しているユーザーって、ほとんどが
こういう種類のユーザーじゃないのかな？
だとすると、GNOMEのバグを直せないばっかりに、大多数のユーザーに面倒を
押しつけてるってことに…
Re: (スコア:0)
ここで一般受けの話を出すのは何故？
この流れで、一般受けしない理由がわかったって何の話？
確認してみました(stretch) (スコア:1)
1. ログインしてtmux
2. top(1)実行
3. デタッチ(Ctrl-b)
4. アタッチ(tmux a) でtop(1)の生存を確認
5. ログアウト
6. 再びログインしてtmux a
no current session.
$ dpkg -l systemd | grep ^ii
ii systemd 230-1 amd64 system and service manager
jessieは大丈夫だった(ずっと似たようなの使用中)
Re: (スコア:0)
補足。
4. と 5. の間は、もちろんデタッチしてます
VNC (スコア:0)
SSHでログインしてVNCServer起動して、いったんログアウトしてからSSHポート転送ツール経由で接続するなんてやってるけど、
そういうのもkillされちゃうってことですよね。
リモート接続関係の解説で修正が結構発生するのでは。
Re:VNC (スコア:1)
VNC serverをsystemd経由で起動していれば大丈夫なんじゃなかろうか(未検証)。
まあ、いずれにせよ、いろんなところに影響しそうですよね。
セーフ (スコア:0)
stableではまだ大丈夫ですね
#KillUserProcesses=no
となっている暗黙のデフォルトをコメントアウトして
KillUserProcesses=no
で明示的に指定すればいいのかな?
# まさかYesで上書いたりしない。。よね。。。
Re:セーフ (スコア:1)
Martinさんのコメント [debian.org]を信じれば、既にrevertされたようですね。
# debian package repoで設定したのか、upstreamで修正したのかはよくわからない.
Re: (スコア:0)
230-2 [debian.org]
debian/rules でコンパイル時オプションを陽に指定したようですね。
Node (スコア:0)
規定値の話だから変えればいいだけじゃね？
Re: (スコア:0)
×規定
本来はこっちが正しい (スコア:0)
ログアウトしたユーザーのプロセスは終了するのが本来の形。
Re:本来はこっちが正しい (スコア:1)
その昔UNIXマシンを多数のユーザで共有していた頃は、
「バックグラウンドでプログラムを動かしたままログアウトするな！リソース不足になるだろ！」
ってよく怒られたものでした・・・
Re:本来はこっちが正しい (スコア:1)
だってコンパイル終わらないんだもん
Re:本来はこっちが正しい (スコア:1)
いやいや、今回の件では、daemon(3) 呼んだプロセスまで殺されるんですよ。
デーモンプロセスは、ユーザー起動であっても、本来は殺されない方が筋。
こういう非互換な変更を平気で入れてくるってことは、systemdのメンテナーは、従来から存在するプログラムとの互換性は気にしないってポリシーなんでしょうね。
今後も同様な問題がたびたび起きそうな予感。
Re: (スコア:0)
伝統的なinit(8)の代わりとして十分モダンで効率的で、かつsystemdのようにシステム全体をLinux cgroup(3)に過度に依存させるようなことを無神経に強要させない、穏やかな設計・実装方針のものが主流に置き換わって欲しい
Re: (スコア:0)
プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
systemdはログインセッション毎にコンテナを作るので、ログアウト後もコンテナが残り続けるなんてのも問題。
Re: (スコア:0)
> プロセスを残すのにSIGHUPの無視を使うなんてのが筋の悪いやり方ですよね。
どういう意味で筋が悪いのでしょうか？
SIGHUPは、セッションの終了を示すシグナルですから、セッション終了時にプロセスが終了しないようにするためにSIGHUPを無視するというのは、ストレートな方法だと思うんですが…
まあイマドキのプロセス構成だと、セッション終了時にSIGHUPが飛んでこないことが多いと思いますが、むしろそれはSIGHUP投げるように直すべきじゃないのかな。
Re:本来はこっちが正しい (スコア:1)
> ①あるユーザーセッションが消費する計算機資源は、そのユーザーセッションとライフサイクルを一致させるべき
> ⇒プロセスも、他の計算機資源等同様、ユーザーがログアウトするのに合わせて終了するのがあるべき姿
もともとUNIXはそうなってますよ。
セッションを管理するセッションリーダーをUNIXカーネルが認識し、セッションリーダーが死んだら、その子プロセスにはカーネルがSIGHUPシグナルを送って殺す仕組みがちゃんとあります。
> ②マルチユーザーシステムにおいては、プロセスは他のプロセスやシステムと協調的に動作すべき
> ⇒システムからの終了シグナルを受けた場合は、それに従って終了するのがあるべき姿
これも当然ですね。
そのためにSIGHUPシグナルが定義されてます。
> 伝統的なUNIXは、これらを無視した「行儀の悪い」スタイルが標準的な方法になっている。
伝統的なUNIXというよりは、GUIユーザー環境が、行儀が悪くできているというのが正しい表現だと思います。
本来なら、GUIユーザー環境のセッションマネージャは、配下のプロセスが、セッション終了時にSIGHUPシグナルを受け取るように手配すべきでしょう。これは、setsid(2) したプロセスがGUIユーザー環境のプロセスを起動するようにするだけで済むので簡単なことです。
そうせずに、daemon(3) API を呼んでデーモン化したプロセスまで殺すような変更をするから、今回、非難を受けているわけです。
> 現行のUNIXのやり方しか知らず、他のシステムの知識もないから、あるべき姿が見えないんだよ。
伝統的UNIXのやり方を知らないのは、はたしてどちらの側なのでしょうか…
Re:本来はこっちが正しい (スコア:1)
> Windowsみたいに、サービスでなければログアウト時にそのユーザーセッションのプロセスは強制的に全部殺すのがあるべき姿。
いやいや、それはありえない。
GUIも持ってるけど、本業は計算処理で、裏で計算するし、ログアウト後、ログインし直したらGUIが復活するプログラムだってあっていい筈だし作れますよ。
CLIのそういうプログラムなら沢山あるわけで。
実際、tmux や screen のユーザーがこれだけ沢山いるってのは、そういう、複数のセッションにまたがる作業の要求があるってことの証明ですよ。
あなた、Windows至上主義になっていて、本来できてしかるべきことができなくなってるってことが見えてないと思いますよ。
囚人が檻の存在を自慢しているようにしか見えません。
Re: (スコア:0)
Windowsは普通にそうなってるよな。必要ならmachine-wideなサービスを作れっていうスタンス。
systemdもそれを目標としてるんだろう。古参連中が理解できないだけで。
Re: (スコア:0)
新しい酒は新しい革袋に。systemd-compatibleなユーザランドだけに浄化した新しいディストロでやってくれ。
Windowsでは当たり前だからといって/bin, /bin/sbin, /usr/bin, /usr/share/binのバイナリに全部".exe"を付けたりはしないだろ?
Cygwin (スコア:2)
よ、呼んだ？
uxi
Re:本来はこっちが正しい (スコア:2)
Cygwin の場合、
現実問題として、.exe 付いてても大してメリットはない気がするんだけど、
逆に .exe 付いてるからと言って大してデメリットが生じてるわけでもないよ。
間に噛んでる Cygwin 層の
システムコールが面倒見てくれるから
ユーザーが書くプログラムでは
.exe 付いてることを意識しなければいけない場面はほとんどないしね。
uxi
Re:本来はこっちが正しい (スコア:2)
そうは読めなかったなぁ。
って書いてあったから、てっきり Windows の /bin その他の話かと。
Cygwin でのメリットは、explorer から見たときに実行ファイルだって分かり易いとか、cmd や explorer から実行できるとかその辺かな？
そういう使い方はあまりしないので、大したメリットではないけど、最低限 mintty とか bash とかは .exe 付いてないと使えない気がする。
uxi
Re: (スコア:0)
プログラムで言うと○○リークとおなじですからね。
今までが異常でUnixの嫌いなとこの１つでした。
initスクリプトもI/Fシカトが多くてイヤだったけどね。
このあたりが組織ごとにバラバラ独自ルール、時によっては真逆の方針生んでたり、バカじゃね？と思ったもんです。
service (スコア:0)
「残したいプロセスはService作ってね」
っていう思考なのかな
ワンショットならcron系と比べて驚くほど手間の掛かる奴だが
Re:service (スコア:1)
systemd-runコマンドを使えば [archlinuxjp.org]サービスファイルを作る必要はないみたいです。