00:00
今回はシステムDについて話していきたいなと思うんですけど、ざっくり自分のシステムDの理解って、OS起動時に自動で何らかのシステムを起動させておける便利ツールみたいな、すごいざっくりとしたイメージなんですけど、これって合ってますかね?
そうですね。大体合ってると思うんですけど、まずシステムDってLinux専用なんですよね。Linuxでしか基本的に動かなくて。
Linuxで、OSで起動するときに最初にプロセスが何かないと何もできないので、まず一番最初にプロセス起動するんですよ。
イニットプロセスって言うんですけど、そのイニットプロセスがシステムDなんですよね。
じゃあもうカーネルレベルというかLinuxの大前提としてシステムDが使われてるっていう感じなんですかね?
そんな感じですね。以前はシステムユニットとか、他のやつもいくつかあったんですけど、今はシステムD以外ほぼ絶滅したというか、あるとは思うんだけど、
少なくとも我々が普段使うようなやつでシステムD使ってないディストリビューションがもうほぼないですね。
なのでもうLinuxと言ったらシステムDっていうセットで考えてもいいんじゃないかなっていうぐらい使われてるシステムですね。
自分がLinuxのディストリビューションをとりあえず使うのだったらDebianとかなんですけど、DebianかUbuntuかなと思うんですけど、
その2つももちろん当然システムD入ってて、イニットプロセスがシステムDで起動してっていうような感じなんですね。
そうですね。もともとシステムD作ったのがRed Hatなんで、最初に入ったのはRed Hat系なんですけど、
その後DebianもUbuntuもシステムDになったんで、今はもうガッツリシステムDですね、両方とも。
なんかディストリビューション間での差異みたいなのってあったりするんですかね、システムDで。
システムDに関しては結構リリースが多いので、バージョン差っていうのはありますね。
結構リリース多いんですね。そんな頻繁にアップデートされてるような印象が正直なかった。
イニットプロセスって結構そこもシステムDが常識変えた部分ではあって、
イニットプロセスって死ぬとLinux全体死んじゃう。最重要って言ってもいいですよ、仕組みとして。
なのでシステムDが出てくる前は、基本的にそんなにたくさん変更を入れないのが結構常識だったんですけど、
そこを壊したのもシステムDだったりするんですよね。
システムDは結構ガンガン機能も追加するし、バージョンも結構ガンガン上げてくる。
なので結構ディストリビューションによって使ってるバージョンに差があるので、そこで機能差が出てるっていうのがありますね。
なるほど。ちなみにそのぶっ壊した要素みたいなのを具体的に教えてもらってもいいですかね。
常識を破壊したのかなと思ったんですけど、システムDが。
生まれた後と生まれる前でどんな感じで変わったんですかね、具体的に。
そうですね。まずなんか、何て言うんだろうな。
03:00
まず昔のSysVユニットって、すっごいなんか今さらなんですけど、すごい大変で、なんかランレベルっていう概念があって、自分もよくわかんないんですけど。
ランレベル。
なんか0から6の数字があって、なんか1だったらこう、2だったらこうみたいな、自分もよくわかんないんですけど、正直意味不明だったんですよ。
その順番に起動してたみたいな感じだったんですけど。
なんかすごいざっくり言うとあれですかね、0から6番までのスクリプトみたいなものが順次実行されてたみたいな感じなんですかね。
ですかね、なんか自分の理解だとそんな感じなんですけど、正直あんま詳しくは知らなくて、正直訳わからないなーって感じだったんですよ。
なるほど。
システムDってすごい明示的で、なんかこのプロセスは、これ例えばネットワークが必要ですよとか、あったらこれが必要ですよとか、あとこれが起動した後に起動してくださいとか、なんかそういうのを設定ファイルで書けるんですよ。
依存関係を組めるって感じですかね。
依存関係が設定で書けるんですよ。で、そうするとシステムDが全部計算して、じゃあこれ起動した後にこれ起動しようとか、でこれとこれ同時に起動しちゃおうみたいな、
平行に起動するみたいなのもできるんですよね、システムDだと。それが全部自動でやってくれますね。
なるほど、じゃあ依存関係というかそのタスクというかプロセスかな、プロセスの依存関係のひも解きみたいなところまでシステムDが管理してるんですね。
そうですね。一応システムDだとユニットっていう単位で管理するんですけど、そのユニットで中でプロセスが起動するっていう感じになりますかね。
じゃあシステムD、単純にすごいシンプルな使い方としてはこのツールをデーモンで起動する、例えばDockerデーモンをOS起動時に実行するみたいな感じの使い方が一番シンプルかなと思うんですけど、
そのDockerデーモンを立てる前に何かを実行するみたいなことも設定ファイルで書けるって感じなんですね、システムDで。
それも書けるし、Dockerみたいなのだとまずネットワークが使えないと起動できないと思うんで、そのネットワークが起動した後に起動しますみたいな設定も書けるし、
それとは別にこのDockerが起動する前にこのシェルを打ってくださいみたいな設定も書けますね。
なるほど、なんか結構理解できてきましたシステムDの成り立ちというか、どう動作してるのかみたいなところが。
なんか他に特徴的なところあったりするんですか、システムDが、いろんなデーモン系のものあるかなと思うんですけど、ツールとかあるかなと思うんですけど、
ここはシステムD独自のものというか、結構尖ってるなみたいなところあったりするんですかね。
正直なんかいろいろある気はしていて、そもそも昔の話しちゃうと、昔ってそのシェルスクリプトを頑張って書かないといけなかったんですよ。
06:01
しかも結構独特な、例えばレビアン系だったらスタートストップデーモンみたいな、本当にデーモン起動するとき以外使わないコマンドを駆使したシェルを書かないといけなかったんですよ、昔って。
そんな書き慣れてる人もいないからめちゃくちゃ大変だったんですけど、今ってシステムDで設定ファイルでこのコマンド起動してくださいみたいな設定するだけで勝手にデーモンにして起動してくれるんですよね。
まずその時点でめちゃくちゃ便利っていうのもあるし、あと他にも以前だと、例えばファイルディスクリプターっていうのを増やしたいってなったときも、実は増やし方があんまり決まってなかったんですよね、昔って。
そうなんですね。なんか一個に定まってるわけではなくて、いろんなやり方がある。
一個に定まってるわけでは、いろんなやり方あるし、物によってはなんかうまく動かないケースもあったんですよ、昔って。
なるほど、あのディストリビューションごとに押さう方が違うってことですよね、それは。
ですかね、いや正直なんかこれは動かないんでやっちゃダメですみたいなのがあったんですよ、昔。
なんでかよくわかんないけど。
アンチパターンがあるみたいな感じだった。
アンチパターンみたいなのが昔あって、けど今はもうシステムDなんで、システムDだともう設定ファイルに書けるんですよ、ファイルディスクリプターの設定。
でそれでも明示的に書けるし、あとそのファイルディスクリプターとかが代表的なんですけど、昔だとそのシェルスクリプトの中に、
Ulimitコマンド使ってファイルディスクリプター直接直すみたいなことをやってる人もいたんですけど、
それやってるとそのシェルスクリプト書き換えちゃってるから、例えばそれがOSのパッケージに入ったやつだったら、
そのOSのパッケージ開けた時にそのシェルスクリプト大書きされちゃったりとかして設定巻き戻っちゃったりとか、
あと例えばOSのバージョンアップした時とかに何か変え忘れるとかありそうじゃないですか、いかにも。
ありそう。
システムDってそのシステムDの設定ファイル直接書き換えるって方法もあるんですけど、それだけじゃなくて、
システムDの設定を大書きする設定ファイルみたいなのが置けるんですよね。
オーバーライトの設定ができる。
オーバーライトの設定ができて、それもシステムコントロールエディットっていうコマンド使うと自動でできたりするんですけど、
それを使うと上書きできるし、それだとOSのパッケージ側で変更があったとしても、
そのオーバーライトはそのまま変わらないので、その設定が使えたりとかもするし、
そういうこれまでのペインが一個一個解消されているというか、
これみんな困ってたんだよねみたいなやつが結構解消されているっていうのがシステムDのすごいとこかなと思ってますね。
なんか今聞いた話だと、何らかのツールをデーモン化する便利ツールではなくて、
OSの設定管理みたいなところまで踏み込んでるんじゃないのかなと思ったんですけど、そうなんですね。
どこまでそう捉えるかっていうのもあるんですけど、
昔はデーモン立てるのもシェルスクリプトで頑張ってたし、
09:01
物によって思い思いのお作法が違ったりとかもしてたんですけど、
今だとシステムDに大統一されて、全部システムDで設定かけばいいし、
あと例えばリスタートっていう設定もあって、リスタートオンフェイリアーとかリスタートオールエイズとかってやると、
プロセスが終了した時に自動で起動してくれたりするんですよね。
これって昔できなかったんで、昔やろうと思ったら、
例えば今更使ってる人いないと思うんですけど、モニットとかスーパーバイザーDとか、
そういうのを使ってそのプロセスを監視させて、もし死んでたら起動させるみたいなのを、
その専用のプログラム使ったんですけど、今だとシステムDでリスタートの設定するだけでそれ全部できちゃうから、
そういうのも全部いらなくなったっていうのもありますね。
しかつ監視までしてくれるからって感じですね、リスタートの処理も。
そうですね、監視もやれますね。監視して自動起動っていうのもできる。
何でもできますね。
そう、システムDね、結構何でもできちゃうんですよ。
何でもできるから、逆に何ができないのかレベルかなと思うんですけど、
そのプロセスを管理することに関しては全てできるみたいな感じなんですね。
もうその何か多分それを目指してますね、システムDは。
たぶん以前のイニットプロセスはさっき言った通り、
あんまり大きくしたくないっていう事情があったから、
機能あんまり足したくないって感じだったんですよね、以前のイニットプロセスの常識として。
システムDはもう全てをやりたいみたいなのを感じますね、見ていて。
なんかそれだけ聞くと、ユニクス哲学とちょっと離れてしまってるのかなと思うんですけど、
ユニクス哲学って1個のことを上手くやろうみたいな概念じゃないですか、
すごいざっくり言うと。システムDなんか全部できちゃっていいのかなと思っちゃうんですけど。
それ結構当時、昔すごい批判されていて、
例えばデビアンもシステムD採用したときに、システムDはユニクス哲学に反してるって言って、
わざわざ報告した人たちもいたんですよ。
けど結局やっぱり便利なんです、システムD。
特に我々みたいなそのウェブのことをやってるじゃないですか、我々って。
そういう人間からするとシステムDめちゃくちゃ便利なんですよ。
マジでいろんな機能使えるんで。
ウェブの人たちが使いたいような機能大体システムD入ってるんで。
なるほど。
結局みんなシステムD使いたかったんですよね。
それもあってシステムD採用しなかったディストリビューションをあんまりみんなが使わなかったっていうのがありますね。
自然に淘汰されていったっていうところがあるんですよね、市場から。
圧倒的に便利なのでシステムDが。
リラックスをカリカリにチュージングして本当に研究目的だったりとか、
あとはウェブ業界だけじゃなくて他の組み込みとか、そういったところだとシステムDもしかしたら使われてない可能性ももちろんありますよね。
12:01
もうちょっと軽量のほうがいいっていうのはあるかもしれないですね。
ちなみにさっき出てきたスーパーバイザーDと若干被るイメージなんですよ、僕自身。
システムDとスーパーバイザーDどっち使おうかなみたいな感じになりがちかなと思うんですけど、
片杉さん的にあったりするんですか、その分け方というか。
今はシステムD一択だと思いますね。
なるほど。
基本的にスーパーバイザーDでやってたことは全部システムDでできるはずです。
逆にスーパーバイザーDなんで使ってたのかみたいなのあったりします?
やっぱりさっき言った視覚監視とかそういうのもできなかったんですよ、以前。
システムDに自動で起動したりとか、そういうのも以前できなかったし、
あとプロセスをデーモン化するだけでも頑張って書かないといけなかったんですよね。
それ書くのすごい大変なんで。
普段のシェルフスクリプトと違うんですよね、ちょっと草法とかが。
なんで書き慣れてる人もほとんどいなかったので、すごい辛かったんですよ。
それでスーパーバイザーD使っててみたいな。
スーパーバイザーとかモニットとかいくつかあったんだけど当時。
そういうのを使ってる人が多かったですね、昔は。
時系列的になんとなくシステムDのほうが昔なのかなと思ってたんですけど、そうじゃないですね。
システムDのほうが新しい?
システムDのほうが新しいですね。
あ、そうなんですね。
全く理解ですけど、もしかしたら調べたら違うかもしれないけど。
かぶってるかもしれないけども、システムDのほうが現時点においては結構いろんな機能があって便利だよって感じなんですね。
そうですね。
じゃあもうほぼほぼデファクトスタンダードはシステムDになりつつあるって感じなんですね。
なりつつあるって完全になったって断言していいんじゃないかなっていう。
じゃあ片杉さんの見てるシステム大体システムD使われてるって感じですか?
もうシステムDじゃないやつ見ないですね、もう何年も。
なるほど。
そんなシステムDなんですけど、一番最初出てきた、何ですかね、更新が結構多いみたいなところがあるんですけど、
開発結構活発なんですね。
開発割と何と比較するかってなると思うんですけど、
イニットプロセスなのかってぐらいには活発だと自分は認識してますね。
イニットプロセスなのかというぐらい活発っていうのはどういう。
イニットプロセスってさっきから言ってる通り、ほとんど変更しないのが常識だったんですよ。
なんでこんなにたくさん変更入れるんだって僕は思ってたりします。
安定性を取ってあんまり変更しないってことですかね。
そうですね。
ぶっ壊れたらOS起動しないかなってことですよね。
ぶっ壊れたらOSが死んじゃうんで、イニットプロセスって。
なのにこんだけ入れてるんだシステムD、変更入れてくるんだっていう感じなんですね。
そうですね。
けどなんかシステムDのせいでなんか困ったみたいなの、昔はあったかもしれないですけど、最近はあんま聞かないような、僕の観測範囲の問題かもしれないけど。
いや全く聞いたことないんですけどね。システムDがアップデートの原因でOSが起動しなくなったとか。
15:06
でも全然変わるんですよね、システムDの立ち位置的には。
そうですよね。かなり依存してるなというか、システムDがスーパーツールすぎて。
そう、システムDが汗が落ちたら全部死んじゃうんで。
ですよね。システムDの死活監視はないですよね。
ないです。
落ちたら終わりですよね。
システムDが落ちたら終わりです、すべて。
ちなみにシステムDのリスタートみたいなのあるんですかね、システムDのデーモンなのかどうかわからないですけど。
ポイントプロセスのリスタートはなくて、OS全体のリスタートと一緒になります。
なるほど、じゃあ再起動しかないってことなんですね。
もちろん設定のリロードとかそういうのありますけど。
なるほど。ちなみにシステムD自体は現在もRed Hatが基本的な開発してて。
基本Red Hat中心の開発の認識ですね。Red Hat以外の人もコミットしてるみたいですけど。
基本的には組織が管理しているOSSみたいな感じなんですね。
に近いかなと思いますね、僕の認識だと。システムDの人に行ったら聞いたら違うって言われるかもしれないけど。
実態はちょっと違うかもしれないけども。
これだけ広くいろんなディジタルビジョンで使われている、しかもユニットプロセスで使われているシステムDで、
組織、1組織が管理してるってなかなか強そうだなと個人的に思います。それだけ見ると。
そうですね、だからやっぱり以前ってRed Hat系とDebian系って結構使い方違ったんですよね。
けどシステムD、全部一気にシステムDになっちゃったから、最近パッケージ管理以外の差が正直あんまりないなって思ってて。
そのくらいシステムDが、こんなにみんなシステムD使うのかってくらいシステムDになりましたね。
みんなRed HatのシステムD使うんだって正直以前思いましたね、その頃は。
いや、すごいですね。聞くまで、この話を聞くまでそこまでの依存度というか、
全てのシステムに対してもう広まりきってるんだなというのは、ちょっと恐ろしくなりますね、ここは。
そうですね、やっぱりLinux Distributionって以前はもっと個性がそれぞれあった認識なんですけど、
最近ほとんどパッケージ管理以外の個性がなくなっちゃったっていうのもありますね。システムDが大統一しましたね。
ちなみにLinux使うのって、大体僕自身の場合、最近だとDockerで使うような感じなんですけど、コンテナで使うんですけど、
そこでもシステムDとかって活躍してるんですかね、Dockerの中で。
Dockerの中では基本的には起動はしてないんですよ。
けど、Dockerを動かすサーバーではシステムDがまず動いているはず。
確かに、Dockerコンテナをホスティングしているサーバーですね。
18:01
サーバーはシステムDで基本的には動いているはず。
確かに。
Dockerの中では動いてないんですけど、あと面白いのがDockerっていくつか機能、Linux管理の機能いくつか使って起動してるんですよね。
なんでかっていうと、他のコンテナから例えば情報が見れないようにするとか、ある程度アイソレートしないといけないとか、そういう機能でLinux管理の機能を使ってるんですけど、
そのうちの一つにCグループっていうのがあって、そのCグループはシステムDがっつり使ってるんですよね。
Cグループっていうのを使うと、そのプロセスを群としてグルーピングできるんですよ。
このプロセスは、例えばCPUこれしか使っちゃダメとか、メモリこれしか使っちゃダメとか、Dockerだと設定したことあると思うんですけど。
設定からできますね、Dockerの。
設定から、Docker設定からできるし、あとDockerのコンテナ側でもコンテナ一つ一つに対してメモリ制限とかできるじゃないですか。
できる。
あの辺の機能で全部Cグループ使ってるんですよ。
なるほど、このグループはメモリ100メガまでだよとかそういう制御。
このプロセスのグループは100メガまでしか使っちゃダメだよみたいなのがDockerだとできるんですけど、あれはCグループ使っていて、システムDもCグループ使ってるんで、システムDでもそのDockerのそういう設定できるんですよ実は。
介入することができるってことですか、Dockerの設定に。
介入というか、ある程度アイソレートされるんで、このプロセスはもうこれしかリソース使っちゃダメだよみたいな設定ができたりします、システムD使って。
なるほど、CグループからシステムDが使われてるんですか、依存関係的には。
CグループっていうのはLinux Kernelの機能なんですよ。
ですよね。
システムDがLinux KernelのCグループっていう機能を使って実装されているって感じですね。
なるほど、じゃあ立ち位置的にはシステムDとDockerは同じってことですよね。
同じLinux Kernelの機能を使っている。
Cグループという機能を使って、機能を実現してるってことですよね。
そうですね。
じゃあシステムDで似たようなことができるってことですね、Dockerと一緒で。
Dockerと似たようなことでできます。
リソースの制御もシステムDでできちゃうってことなんですね。
できちゃうんですね。
あんまそうやってるの、あんま見たことない気もするんですけど、結構やってますか。
僕は結構やっちゃいますね。
なるほど、どういうので具体的に。
例えばセキュリティ系のツールっていきなり暴走されると困るじゃないですか。
セキュリティ系のツールってユーザーに直接影響しちゃよくないと思っているので、
小さいリソースでゆっくり動いてくれたらそれでいいっていうものじゃないですか、セキュリティ系のツールって。
そうですね。
セキュリティ系のツールのリソースを絞りたい。
例えばこのセキュリティ系のツールはプロセスはCPU1個しか使っちゃダメだよとか、メモリーここまでしか使っちゃダメだよとか、
そういうのが実はシステムDで簡単にかけたりするんですよ。
めっちゃ便利ですね、それ。
21:02
このツールはCPUをこれだけ使っていいよとか、あとはこのツールはこのぐらいメモリーマックスに使ってくださいとか、
そういうリソースの振り分けができるからこそ柔軟に振り分けができるって感じですよね。
そうですね。
それがあれなんですかね、今言ってもらったセキュリティのツールの中からシステムDを呼び出してって感じなんですか、使い方的に。
違います。システムDが起動してるんですよ、そのプロセスを。
なるほど。
そのシステムDが起動するときにCグループを使ってプロセスをグルーピングしてくれるので、
Linuxカーデルの機能でこいつらはこれしか使っちゃダメだっていう形で起動してくれるんですよ。
理解。
だとするとあれですかね、ユーザーへの使い方の提示方法としては、
そのセキュリティツールの使い方のリードミーのところにシステムDのコンフを書いておくみたいな感じなんですかね。
こうやって使うとCPU使いすぎないよみたいな。
っていうのは実は自分が作った結界っていうセキュリティ系のツールなんですけど、
それのリードミーにそういうこと書いてありますね。
システムDでこういうふうにやるとより安全に使えますよみたいなのを書いてたりします。
そういう形で起動してね、みたいなシステムD使うのがお勧めだよみたいな感じで設定を書いたりと。
一応ちょっと話それるんですけど、結界は一応リソースゆっくりやるとかそういう機能あるんですけど、
でもそれでも信用できないというか、暴走する可能性ってゼロじゃないじゃないですか。
そうですね。
なので暴走されたとしてもシステムDのCグループの中で使っておけば、
Cグループの中でしか暴走できないので、より安心したい場合はこうしてくださいっていう。
一応機能としてそういう機能は提供しているけどっていう感じですね。
なるほど。システムDの方がそこら辺のシステムD経由でCグループ使う方が、
リソースの制御面に感謝を確実に借れてるってことですよね。技術的に。
借れてるとか基本的に使えないですよ。LinuxKernelがそれしか渡してくれないから、それ以上絶対使えないですよ、プロセス側は。
仕組み的にリソースの割り当てをされないんですね。
割り当てしてもらえない?LinuxKernelから。
そういう感じなんですね。
だからどんなに頑張っても無理なんですよ。それ以上使えないから、絶対安心っていう感じですね。
安心感が強い。システムDを使えば。
そうですね。なんで結構その使い方をお勧め、個人的にはお勧めというか、いうことありますね。こうしたらいいっていうのは。
なんか今の話聞いてるとやっぱりインフラですよね。システムDを使うような人って、
システムDをかなり使う人ってウェブのアプリケーションを作るというよりかは、
サーバーを良い感じに運用していく人向けのツールなのかなと思うんですけど、現時点においては。
あとシステムDで独特なところとかって何かあったりするんですかね。
24:00
例えばプロセス、システムDで管理しているプロセスのシグナル、いろいろあるかなと思うんですけど、
キルモードだったりとかで制御できるみたいな機能があるって聞いたんですけど、そこら辺独特だったりするんですか。
そうですね。そもそもLinuxKernelのプロセスの考え方を伝えた方がいいかなと思っていて、
まず大前提としてLinuxKernelってプロセス作る機能ってないんですよ、実は。
プロセスを作る機能がない。
プロセスを作る機能ってなくて、イニットプロセスだけを作るんですけど、それ以上のプロセスって作る方法ないんですよ。
じゃあどうするかっていうと、フォークって言って、自分のコピーを作る方法しかないんですね。
プロセスを作る方法はなくて、自分自身のコピーを作る方法しかないんですよ。
なのでLinuxKernelの全てのプロセスはシステムDのプロセスの子どもプロセスになってるんですよ。
なるほど。じゃあイニットプロセスをフォークしていってるんですね、全てのプロセス。
そう、全てがイニットプロセスをフォークしたプロセスのさらにフォークかもしれないけど、
全てのプロセスはシステムDのイニットプロセスの子どもなんですよね。
なるほど。
Linuxの場合。で、まずシステムDからフォークしましたと。
で、そのプロセスがフォークしたプロセスがさらにフォークして自分のプロセス作りましたと。
で、親プロセスが自分自身が死にましたと。
死んだ場合、子プロセス、自分が作った子プロセスは自動的に自分の親、今回の場合システムDのプロセスに変わるんですね。
Linux kernelの機能として。
親が異常されるってことですかね。
そうですね。その親が死んだら、孫プロセス、まあ孫プロセスって言わないかもしれないけど、孫のプロセスは子どもになるんですよ。
親が変わるんですよ。
親が変わる、すげ変わるというか。
っていうのがLinux kernelのデフォルトの挙動なんですけど、実はこれシステムDだと当てはまらなくて。
そこがまずLinux kernelの挙動と違うっていうことを説明しないといけないんで、こういう説明したんですけど。
大前提、Linux。
大前提、さっき言った挙動になるんですよ、大前提として。
けどシステムDだとそうはならないケースがあって、だから多分最近Linux kernel触り始めた人はそもそもそういう挙動だって知らない可能性もあって、
なんでかっていうとシステムDだと挙動が違うからです。
なんでかっていうとさっき言ったCグループと関係があって、デフォルトの設定だとそのCグループ全体を一緒に管理するっていう感じになっていて、
そのプロセスが死んだらそのCグループ全体をキルするっていう設定になってるんですよ、実は。
なるほど、じゃあ子供、孫、諸党も全部殺すってことなんですね。
しかもシグキルを送ってくるんで、本当に親プロセス死んだらそのCグループ全体のやつはいらないよねっていう判断になっちゃうんですよ。
27:04
なるほど、全て死ぬ。その親プロセスがExit0とか入って終わった時点で終わるってことですね。
終わったら全部死にます。で、キルモードのデフォルトの設定だとそうなっていて、これだと困るプロセスたくさんあるんですよ。
さっき言った通りLinuxKernelのデフォルトの挙動と違うんで、それだと困るっていうプロセスは結構たくさんあって、
なのでそういう場合はキルモードを変更しないといけないです。これ結構自分ハマったことあるので、結構気をつけてほしいっていう、
なんか個人的にシステムDで気をつけてほしいことありますかって聞かれたら絶対にこのキルモードは伝えてますね。
特に昔からLinux使ってる人は絶対ハマるんで。
システムDのオプションとしてキルモードが実装されてるってことですよね。
オプションってかデフォルトの挙動がさっき言った全部殺すっていう設定なんですよ。
デフォルトのキルモードがコントロールグループっていう設定になってる。
そうですね、っていう設定になっていて、Cグループ丸ごと全部死に殺します。
しかもシグキルなんで、シグキルって何が厄介かっていうと、シグキル以外だとシステムコール呼び出しがあるので取れるんですよ。
このシグナル来たなっていうのは取れるんですけど、シグキルだけは取る方法がなくて、もうLinux管理所で強制的に殺されちゃうから。
それは親プロセスだけじゃなくて子プロセスでもシグキルでなければキャッチできるけどもってことですかね。
シグキル以外だと、例えばシステムコールのエストレースっていうのを使うと、そのプロセスに対してどういうシステムコールが実行されたかって取れるので、
例えばシグタームが来たとかだったら取れるんですけど、シグキルだけは取る方法がないんですよね。
強すぎるシステムコールってことですよね。
強すぎるっていうか、Linux kernelの機能として強制的にシグナル送るというか、完全に強制的に殺しちゃうんで取れないんですよ。
なるほど。
僕初めてシステムD使った時に、なんかプロセスが死ぬけどこれLinux kernelの挙動としてはおかしいってなって、
システムコールでどういうシグナル来てるか取ろうと思ったんだけど取れなかったんですよ。
取れないってことはこれシグキルが送られてるとしか思えないんだけど、シグキル送ってるとしたらシステムDがありえないんだけど、そんなことするかと思って調べたらこのキルモードっていうのがあって、
なんと殺しに来るっていうことがわかる時にマジかって昔になりました。
ちょっと最初のハマりポイントってことですね。
基本ハマると思いますね。
なんで僕は聞かれたら必ずこれは気をつけてくださいって言ってます。
このキルモードも色々多分設定値あると思うんですけど、ざっくりどれにしたらいいんですか?
物によるとしか言いようがなくて、
NANっていう設定もあるんですけど、NANにすると色々プロセスキルしなくなっちゃうので、
30:06
そのプロセス完全に自作していて、自分で完全にコントロールしたいとかだったらいいかもしれないんですけど、
そうじゃなければ他のキルモードにしてうまく付き合うのがいいのかなと思いますね。
自分が管理したい手法によってキルモードをコントロールするべきだっていうことですね。ちゃんと把握して。
ちゃんと挙動を把握して、適切なキルモードを自分で作っているプロセスだったら選択すべきだと思いますね。
一番最初に言ってもらった大前提のLinuxのプロセスの挙動、親に昇格するみたいな挙動を知らなければ、
逆に言えばシステムDのこのキルモードのCグループ全体を殺すっていう挙動は何となく直感的な気がするんですよね、自分的には。
そうですね。Linux管理のデフォルトの挙動を知らない人は結構いるんですよね。
親プロセス死んだら子プロセスも全部死ぬと思ってたって人いるので、そういう人にとっては逆にむしろデフォルトの方がシンプルではある。
わかりやすいですよね。なんか親死んで子死ななかったらゾンビプロセス出来上がりそうと思うんで。
変な実装するとなるかもしれないですね。
じゃあちょっとここのキルモードに関しては気をつけないといけないということですね。
他にシステムDでここは気をつけろというか、これ面白いぞみたいな話あったりしますか。
そうですね。個人的にすごい面白いなと思ってるのが、ソケットアクティベーションっていう機能で、そんなに有名な機能ではないと思うんですけど、
このソケットアクティベーションっていう機能は、そんな頻繁には使わないんですけど結構面白いと思ってますね。
どういう感じなんですかね、ソケットアクティベーション。
なんかそのシステムDがソケットを起動して、そのUNIXドメインソケットでもいいし、あと普通にTCPのポート番号とかでもいいんですけど、
それをシステムDが開いてくれる。
で、そこに対してリクエストを飛ばすと、そのシステムDがそのシェルスクリプトみたいなのを設定しとけば、そのスクリプトを実行してくれるんですよね。
なのでCGIみたいなことができるんですよ。
めちゃくちゃ便利じゃないですか、それ。なんか簡単にローカルのAPIを作れるみたいな感じですよね。
昔だとExiNetDっていうのがあって、このExiNetDで似たようなことができたんで、こういうことをやりたかったらExiNetD使ってたと思うんですけど、
今はExiNetDもいらなくて、システムDのソケットアクティベーションを使えばそういうこともできちゃうんですよね。
めちゃくちゃ便利。なんか今パッと思いついた用途であるのが、例えばCLIとか作るじゃないですか。
そのCLIが認証を求めるときっていろいろあるかなと思うんですけど、
33:00
AWSのトークンを必要とするときに、GitHubかな、GHコマンドとかGHログインとかするとブラウザに飛んで、
その間GHコマンドはローカルでサーバーを立てておいて、ブラウザでコールバックしてくるみたいなのがよくありがちじゃないですか、そういうCLIって。
そういうときに待ち受けるポート、サーバーみたいなのを、
CLI側がサーバーを立てることなく、ウェブサーバー立てることなく、
このソケットアクティベーションだけで実現できそうですよね。
今言った用途で使うとセキュリティ的にどうなんだっていうのはちょっと考えられてないんだけど、
今言ったサーバー立てるのって結構大変だし、
そのサーバーが動いてるか視覚監視するとかも結構大変なんですよね。
やっぱりそのプロセス1個立てちゃうと、ちゃんと監視しておかないといけなくなっちゃう。
システムでのソケットアクティベーションを使うと、あるケースが来たタイミングで実際にそのスクリプト叩いたりするから、
そういうのはいらないし、CGIと全く一緒かっていうとそうではなくて、
CGIって環境変数にいろいろ入れてきたりとか、
HTTPを解釈して使いやすくしてくれたりとかするんですけど、
ソケットアクティベーションはそういうことは一切なくて、
これも設定によるんですけど、
設定すると標準入力にリクエストのパケットがそのまま入ってきて、
レスポンスも標準出力にそのまま1個1個返していけば、
HTTPだったらHTTPのやつを1個1個返していけば、
そういうレスポンス返せるみたいなことができるんですよね。
自分の想定した用途としては、
AWSのEC2みたいな環境だと使うかわかんないんですけど、
例えばオンプレミスの物理サーバーだと、
例えばDELLだと、DELLにしか使えないHTTPのリクエストのAPIみたいなのが
各サーバーに立てたりするんですよ。
けどそれがローカルじゃないと取れなくて、
けどそういうの使うと、あとコマンドってケースもあって、
そのサーバー上でコマンド叩くと機能が使えたりとかする。
例えばCPUの温度が取れるよとか、バイオスのバージョンが取れるよとか、
そういうサーバー管理みたいなAPIとかって、
基本物理のサーバー上でしか叩けないって結構あるんですよ。
そういうのを、例えば外から叩けるようにしたいとかってなると、
じゃあそれを普通に叩くサーバーを用意するかっていうと、
やっぱりそれって高コスト、滅多に叩かないのに、
そのサーバー用意するの大変だし、
それを例えば変更したい時にデプロイ大変だよねとかあるじゃないですか。
けどこれだと、そのセックスクリプト叩くだけでできちゃう。
結構そういう特にオンプレのケースで便利なんじゃないかなと思ってますね。
36:00
VMとかだったらプロセス立てた方が結局楽なんじゃないかなとは思うんですけど。
今の用途だったらSSHで入って実際にコマンド叩くみたいなのが
大体主眼なのかなとは思うんですけど、
それではなくてシステムDのこのSocket Activationを使った方が
いい場面もあるよねって感じですかね。
なんかそのAPI作りたい場合ですね。
例えばそのBIOSのバージョンを前代の、
全サーバーのBIOSのバージョンを取得するAPI作りたいとか。
あとはもっと踏み込んでBIOSのバージョンアップとか、
そういうの自動化したいとか、
そういうのやるとそのAPI、ローカルからAPI叩けないといけないから。
そういうケースだとそういう仕組み作るしかなくて、
そうなるとシステムDのSocket Activationは結構ちょうどいいんじゃないかなと思ってますね。
確かに便利そう。
なんか色々やりようというか便利なタイミングありそうだなと思ってて。
で単純に知らないですね。
システムDでこういうSocket Activationができるっていうのは。
あんまり知られてないと思いますね。
知らないので選択肢として上がらないですね。
何かやりたいっていう時になった時に知らないから。
なのでね結構個人的には結構好きな機能なんで、
あんま使わないんですけど。
でも面白い機能ですね。
面白いですね。
他にあったりします?
意外となんかそれ自分の会社でも使ってるんですけど、
クーロンって1分より短いの設定できないんですよ。
小数点でかけりゃって感じですかね。0.5。
1回の処理だったらいいんだけど、
例えば30秒に1回やりたいとか、1秒に1回処理したいとか。
あと他にも例えば0時ぴったしじゃなくて、
1時間ごとにざっくり動けばいいよとか。
あってただちょっとバラしてほしいみたいな。
0時ぴったしだと負荷が上がっちゃう。
0時ぴったしに来るリクエストが多いとか結構あるんですよね。
0時ぴったしにクーロンとか実行されてるから、
0時ぴったしだと負荷が上がって嫌だとかってあるんですよ結構。
ありがち。
なんでランダムに1時間ごとぐらいにやってほしいとか、
そういう設定ってクーロンだとかけないんですよね。
かけないですね。確かに。
でもシステムDだとシステムDタイマーってやつがあって、
今言った設定全部かけますね。システムDタイマーだったら。
ランダムにするのもできるし、1秒単位もできるし。
1秒単位とか1分より短いのもできますね。システムDタイマーなら。
なんでもできるじゃないですか。システムDも。
システムDマジで便利ですよ。
タイマーユニットを使って、
指定のプロセスを実行するってことですよね。
そうですね。
完全にクーロンかなとは思うんですけど。
クーロンですよ。完全に。
クーロンより機能が明らかに多いって感じですね。
39:01
じゃあなんでみんなクーロン使ってるんですかね。システムD使えばいいじゃないか。
クーロンで例えば100個ぐらいクーロンで設定ありますとかってなると、
システムDの設定100個かける2か、200個ぐらい作らないといけないから、
ちょっと面倒くさいは面倒くさいですね。
簡潔にクーロンの方がかけるってことですね。
1行書くだけなんでクーロンって。
確かに。
その簡潔さはないと言えばないですね。
ただ柔軟性はシステムDに分があるっていう。
システムDタイマーの方が圧倒的に設定多いですね。
この機能も全く知らないですね。
単純にもうマジで一番最初に言った通りシステムDは
OS起動の時にプロセスを自動で立ち上げてくれるくんだと思ってたので、
今の話聞いてる中でもめちゃくちゃ機能あるなと思って。
めっちゃ機能あって便利ですよシステムD。
これ聞いただけでシステムDちょっと使いたくなってきたんで、
なかなかいい話だなと思ったんですけど、
いい時間なので最後にシステムDに関して言いたいことあったらお願いします。
そうですね。
システムD最初僕が初めて使ったときは正直さっき言った
Linux kernelの挙動と違うとか、
何の機能があるか分かんないとか、
そういうので結構戸惑いはあったんですけど、
今のLinuxってシステムDなし、
Linuxってもうないんですよね今。
全部もうシステムDで使うって前提なんで、
今ってLinuxイコールシステムDと言っても過言ではないぐらい使われてるので、
みんなシステムDと仲良くできたらみんなハッピーなんじゃないかなと思ってます。
ありがとうございます。
ということで今回はここまでにしたいと思います。
Yahoo! YorosuのOSSでは毎回一つのOSSを取り上げて、
それについて片付いたエンテコで、
技術的なところも深掘りしながら話をしていく番組になってます。
今後もその名の通りYahoo! YorosuのOSSを取り上げていきたいなと思ってますので、
ぜひお聞きのプラットフォームでフォローと高評価のほうをお願いします。
またこのOSSについても取り上げてほしいなどありましたら、
コメントとかあとはXなどで教えていただけると嬉しいです。
番組についての感想も非常にお待ちしておりますのでよろしくお願いします。
XなのでつぶやくさいにはハッシュタグYahoo! YorosuのOSSをつけてください。
それでは今回もありがとうございました。
ありがとうございました。
