アカウント名:
パスワード:
リンク先にも書いてありますが、そもそもはGNOMEだとログアウト時にgnome-keyringとかのプロセスが残ってしまい、ログインログアウトを連発するとゾンビ化したプロセスが多発することが理由のようです。https://bbs.archlinux.org/viewtopic.php?id=204307 [archlinux.org]https://bugs.freedesktop.org/show_bug.cgi?id=94508 [freedesktop.org]黙って変更したわけじゃないんだからこっちで対応すりゃいいだけの話じゃん、と気にならないのは少数派なのか。
慣例に従って書かれた今までのコードすべてとの互換性を壊してしまうような変更だから問題になるのでしょう。
http://www.glamenv-septzen.net/view/854#idf2f03a [glamenv-septzen.net]setsid、signal まわりで対応していた世界に「PAMで新規セッションを作成しろ」というのは筋が悪いと思います。
X のログインと TTY のログインがかけ離れているのに、同じ枠組みで取り扱ってきたのが問題のような気もします。
同意。慣例じゃなくて仕組みかな。
CUIなら PID, PPID, PGID, SID, TPGID, tty あたりがあれば一通り問題なく動くからねぇ…。ただ、これらのIDは擬似端末とプロセスと標準入出力に紐づいた仕組みで、GUI(desktop session) を管理するには足りないのは分かるがGUI用の仕組みを作るのが筋であって、巻き添えにするのは違う。
セキュリティ、オーディオ、文字入力、クラウドサービス等でユーザー単位のデーモンを作る時って、logout時に正しく終了させるというのは結構難しいんですよね。知らない間にorphanになってて、それを検出する良い方法も無いですし。
systemdは同じsessionに属するプロセスをorphanでも追いかけれるんでlogout時にclean upできるのはありがたいですが、普通にやっちゃうと互換性が無くて怒る人たちが多いようです。いっそのことorphan processにもSIGHUPを送れば良いんじゃねと思ったりしますが変ですかね？(理想的にはsignalの新設なんかも)
> セキュリティ、オーディオ、文字入力、クラウドサービス等でユーザー単位のデーモンを作る時って、logout時に正しく終了させるというのは結構難しいんですよね。知らない間にorphanになってて、それを検出する良い方法も無いですし。
本物のデーモンなら難しいですが、GNOME 関係ならユーザーとの対話を伴うようなプログラムでしょうし、単にユーザーセッションに対応するプロセスグループを作ってそれに属させておいて、ログアウト時に、SIGHUP をプロセスグループに送ればいいと思うんですが、それでなにか問題があるのでしょうか？
そのようにしないプログラマが多すぎるからゾンビが残っちゃうんでしょ。
だからと言ってsystemdがデフォルトでやることなのか？と言うと、……どうなんだろう。今やsystemdはレイヤーが広すぎて守備範囲と言えるのかどうかさっぱりわからない。
> そのようにしないプログラマが多すぎるからゾンビが残っちゃうんでしょ。
それはおかしいですよ。SIGHUP を送るようにするなら、送る担当は GUI toolkit のセッションマネージャーです。GUI toolkit のセッションマネージャーを作るプログラマなんて、世界で10人もいませんよ。
アプリケーションプログラマーは何もしなくても良いはずですが。
セッションの終了時にプロセスが正しい順序で終了しないとorphanになってシグナルの送り先が見失われるのと、そもそもSIGHUPは端末の終了であってセッションの終了ではないというのが問題なんだと思います。
ちなみに、この投稿時にsradの下に出てました > "UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア"
> セッションの終了時にプロセスが正しい順序で終了しないとorphanになってシグナルの送り先が見失われるのと、
プロセスグループに関して誤解があると思います。シグナルの送り先がどういう順序で終了しても（たとえプロセスグループリーダーが先に終了しても）、子孫プロセスが1つでも残っていればプロセスグループは残りますし、シグナルを送ることができます。
> そもそもSIGHUPは端末の終了であってセッションの終了ではないというのが問題なんだと思います。
SIGHUP が端末の切断であったのは確かだし、今でもその意味は残っていますが、現在ではセッション終了時には端末とは関係なくとも、orphaned process group には送られるシグナルとなっていますから、端末の終了に限定する必要はありません。
なお、daemon(3) を呼べば、process group が切り替わりますから、今回のsystemd の件のように巻き添えをくらう心配はありません。
> リンク先にも書いてありますが、そもそもはGNOMEだとログアウト時にgnome-keyringとかのプロセスが残ってしまい、ログインログアウトを連発するとゾンビ化したプロセスが多発することが理由のようです。
要はGNOMEのバグがとれないから、GNOMEを直すんじゃなくて、従来から存在する大量のプログラムに対して、非互換な変更を押し付けるってこと？
> 黙って変更したわけじゃないんだからこっちで対応すりゃいいだけの話じゃん、と気にならないのは少数派なのか。
基盤ソフトウェアを保守する立場からすると、ありえないですね。基盤的なソフトウェアの場合、従来からその基盤に依存しているアプリケーションとの互換性を維持するというのは、普通なら相当に優先度が高い目標です。バグを直すんじゃなくて、互換性を壊して誤魔化すとか、ありえない選択かと。正常な判断力があれば、バグを直すことで対応するのでは？
正常な判断力があれば、バグを直すことで対応するのでは？
正常な判断力があればより簡単な方をとるあとまあSystemdは既存のinitのようなソフトウェアの欠点を克服が最優先なので相当に優先度が高い程度の目標であれば無視されるだろうな。どうせオプションいじれば済む問題ですし。gnomeはgnomeで互換性の確保なんてどうでもいいことより改善を優先している組織ですし。
GNOMEをkillしちゃえよもうなんでGNOMEの問題に他が巻き込まれにゃんらんのだ
Systemd使うの諦めれば済むだろ。
脈絡のないものを並べるとか批判と戦いたいだけにしか見えないな。
改「善」と言う辺り有用性は認めているからそういった「意見が参考にならない人間」がどういった思考しているのか、もう少し詳しく教えて
違います。彼らにとって、「改善」とは、既に「善」であった物を「改」する行為のことを意味します。つまり、余計なことという意味です。
鬼と会ったら変えれ・・・・・・何か違う
いや、普通にそうでしょ？頑固に7だの8.1だの使い続けても面倒なだけじゃんメジャーな製品を使う時は、長いものに巻かれとくのが正解。
そして，熊本地震のボラセンでWin10のアップグレードがはじまって業務が止まったり，WiFiルータの帯域を3日で食い尽くしたりするのですね# 聞いた話なので詳細は記憶違ってるかもしれませんが，実話だそうです
アプリってのはWordとExcelとPowerPointのことなんだよ、普通の人間にとってはね。
そのアプリにsystemdが加わる流れか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
変更には理由あり (スコア: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: (スコア:0)
だからと言ってsystemdがデフォルトでやることなのか？と言うと、……どうなんだろう。
今やsystemdはレイヤーが広すぎて守備範囲と言えるのかどうかさっぱりわからない。
Re: (スコア:0)
> そのようにしないプログラマが多すぎるからゾンビが残っちゃうんでしょ。
それはおかしいですよ。
SIGHUP を送るようにするなら、送る担当は GUI toolkit のセッションマネージャーです。
GUI toolkit のセッションマネージャーを作るプログラマなんて、世界で10人もいませんよ。
アプリケーションプログラマーは何もしなくても良いはずですが。
Re: (スコア:0)
セッションの終了時にプロセスが正しい順序で終了しないとorphanになってシグナルの送り先が見失われるのと、そもそもSIGHUPは端末の終了であってセッションの終了ではないというのが問題なんだと思います。
ちなみに、この投稿時にsradの下に出てました > "UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア"
Re: (スコア:0)
> セッションの終了時にプロセスが正しい順序で終了しないとorphanになってシグナルの送り先が見失われるのと、
プロセスグループに関して誤解があると思います。
シグナルの送り先がどういう順序で終了しても（たとえプロセスグループリーダーが先に終了しても）、子孫プロセスが1つでも残っていればプロセスグループは残りますし、シグナルを送ることができます。
> そもそもSIGHUPは端末の終了であってセッションの終了ではないというのが問題なんだと思います。
SIGHUP が端末の切断であったのは確かだし、今でもその意味は残っていますが、現在ではセッション終了時には端末とは関係なくとも、orphaned process group には送られるシグナルとなっていますから、端末の終了に限定する必要はありません。
なお、daemon(3) を呼べば、process group が切り替わりますから、今回のsystemd の件のように巻き添えをくらう心配はありません。
Re:変更には理由あり (スコア:1)
> リンク先にも書いてありますが、そもそもはGNOMEだとログアウト時にgnome-keyringとかのプロセスが残ってしまい、ログインログアウトを連発するとゾンビ化したプロセスが多発することが理由のようです。
要はGNOMEのバグがとれないから、GNOMEを直すんじゃなくて、従来から存在する大量のプログラムに対して、非互換な変更を押し付けるってこと？
> 黙って変更したわけじゃないんだからこっちで対応すりゃいいだけの話じゃん、と気にならないのは少数派なのか。
基盤ソフトウェアを保守する立場からすると、ありえないですね。
基盤的なソフトウェアの場合、従来からその基盤に依存しているアプリケーションとの互換性を維持するというのは、普通なら相当に優先度が高い目標です。
バグを直すんじゃなくて、互換性を壊して誤魔化すとか、ありえない選択かと。
正常な判断力があれば、バグを直すことで対応するのでは？
Re: (スコア:0)
正常な判断力があれば、バグを直すことで対応するのでは？
正常な判断力があればより簡単な方をとる
あとまあSystemdは既存のinitのようなソフトウェアの欠点を克服が最優先なので相当に優先度が高い程度の目標であれば無視されるだろうな。どうせオプションいじれば済む問題ですし。
gnomeはgnomeで互換性の確保なんてどうでもいいことより改善を優先している組織ですし。
Re: (スコア:0)
GNOMEをkillしちゃえよもう
なんでGNOMEの問題に他が巻き込まれにゃんらんのだ
Re: (スコア:0)
Systemd使うの諦めれば済むだろ。
Re: (スコア:0)
脈絡のないものを並べるとか
批判と戦いたいだけにしか見えないな。
Re: (スコア:0)
改「善」と言う辺り有用性は認めているから
そういった「意見が参考にならない人間」がどういった思考しているのか、もう少し詳しく教えて
Re: (スコア:0)
違います。
彼らにとって、「改善」とは、既に「善」であった物を「改」する行為のことを意味します。
つまり、余計なことという意味です。
Re: (スコア:0)
鬼と会ったら変えれ・・・・・・何か違う
Re:変更には理由あり (スコア:1)
いや、普通にそうでしょ？
頑固に7だの8.1だの使い続けても面倒なだけじゃん
メジャーな製品を使う時は、長いものに巻かれとくのが正解。
Re: (スコア:0)
そして，熊本地震のボラセンでWin10のアップグレードがはじまって業務が止まったり，WiFiルータの帯域を3日で食い尽くしたりするのですね
# 聞いた話なので詳細は記憶違ってるかもしれませんが，実話だそうです
Re: (スコア:0)
アプリってのはWordとExcelとPowerPointのことなんだよ、
普通の人間にとってはね。
Re:変更には理由あり (スコア:2)
そのアプリにsystemdが加わる流れか
敢えて言おう。カスである！と。