[過去ﾛｸﾞ] Debian GNU/Linux スレッド Ver.93 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
308: 2019/12/17(火)01:40 ID:N3b7qwB4(1) AAS
systemdが使用してるメモリ量ってどこを見ればいいの？
少ないんだとは思うけどユニットファイル追加したらどれくらい増えるんだろうか？
309: 2019/12/17(火)01:40 ID:M7RKHLks(1) AAS
Systemdの使用法書かれた記事はあっても
initと数値を比較して優位性を示した記事は見たことがない
メリットとされていたのは口先だけの誤魔化しで実際はデメリットばかり
ブラックボックス化して悪巧みしたいのだろうとだけ感じる
310: 2019/12/17(火)05:09 ID:9RFGRp92(1) AAS
systemdのメリットは数値じゃなくて便利さでしょ？
initが起動時したときだけの処理をしてるのに対して
systemdはシステムの動的な変化をトリガーに処理を行う
システムが起動した時だけじゃなくて
ディスクがマウントされたとか特定の時間になったとか
ネットワーク構成が変わったとか
数値の前にinitは機能が足りてないんだよ。
あとinit.dのスクリプトが面倒くさい。自分でpidファイルを作ってとか
start/stop時の処理を書いてとかやらないといけない。
自分で新しいアプリを作ったときに必要になるコードの量がぜんぜん違う
省1
311(1): 2019/12/17(火)06:26 ID:UTO5VfwP(1) AAS
毎回ゼロからでなし
比較として適切かどうか
「Java はコードが長いからダメ」っていうのとどう違うか説得力もたせないと
312(1): 2019/12/17(火)10:46 ID:JaRFpJrg(1) AAS
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
7b77e0f2-4ff9-4adb-85e4-af249191f27a
[ ] Choice 1: F: Focus on systemd
[ ] Choice 2: B: Systemd but we support exploring alternatives
[ ] Choice 3: A: Support for multiple init systems is Important
[ ] Choice 4: D: Support non-systemd systems, without blocking progress
[ ] Choice 5: H: Support portability, without blocking progress
[ ] Choice 6: E: Support for multiple init systems is Required
[ ] Choice 7: G: Support portability and multiple implementations
[ ] Choice 8: Further Discussion
省3
313: 2019/12/17(火)12:33 ID:OlEawMzQ(1) AAS
systemctl statusは便利
314: 2019/12/17(火)15:58 ID:UW9yVEU1(1/3) AAS
あと/etc/systemd以下にファイルを配置することで
簡単にデフォルト設定を変更できるのもいいな
以前はインストールすると勝手に起動するサービスを
停止させるのは面倒だった
315: 2019/12/17(火)16:05 ID:UW9yVEU1(2/3) AAS
>>311
Javaのコードの長さは型情報の追加という意味があるから全然話が違うよ。
init.dの場合、initが面倒を見てくれれば書かなくて済むものを
自分で書かなければいけない。しかもそのやり方はディストリごとに
パスが違ったりと微妙に異なる可能性がある。
なにより量が違いすぎる。/etc/init.d/cronは少ないほうだと思うが92行もある
それに対して/lib/systemd/system/cron.serviceは12行
316: 2019/12/17(火)16:11 ID:UW9yVEU1(3/3) AAS
>>312
今のままのinitの使い方はやめるべきだと思うな
init自体はそのままでも良いと思うんだけど、
init.dのスクリプト群にフレームワーク的な構造をを取り入れて
処理を共通化するべきだろう。そしておそらくそれはできる。
start/stop/status的なものはデフォルトで共通処理
そしてオーバーライド可能とかね
そうしないとメンテナンスが大変すぎる。
317(1): 2019/12/18(水)03:45 ID:RepDV8Lm(1) AAS
Debianをsystemdに売り渡した連中がデカイ面してるので
出ていった半数のメンテナは戻ってこない
つまりDebianが暗黒面に落ちたから*BSDへ移る用意をしておけということだ
318(1): 2019/12/18(水)06:20 ID:MB7RJ0fN(1) AAS
要するに、sysvinit かなにかをデフォルトにして
「選びたければ systemd にしな」というかんじにしたい人が結構多いのかな
319: 2019/12/18(水)07:44 ID:zH1F31WX(1) AAS
>>317
そんな事言っちゃっていいの？
間違いなくドライバ云々で苦労する人続出だよ
320: 2019/12/18(水)08:41 ID:O+Yu98Ta(1/4) AAS
systemdってexponential backoffないのか？つらいな
デフォルトは10秒間で5回まで再起動が行うっていうけど
起動に3秒ぐらいかかってるから、10秒で5回の閾値超えないんだよな
つまり永遠に再起動を繰り返す。
ちゃんとそこまで確認して設定すりゃいいんだろうが
簡単にミスしてログでディスク枯渇してしまう
321: 2019/12/18(水)09:53 ID:0A9rzvn8(1) AAS
>>318
blogでどう投票したかを表明している人の内容を見てる感じ
systemd推進派とinit多様性維持派で半々ぐらいの印象
まあN=1桁だけど
322(1): 2019/12/18(水)12:59 ID:gMdqO2R6(1) AAS
systemdオンリーにする方針は
何年かしたら再考しようと誰か言い出すし
蒸し返すの禁止にも出来ないし
323: 2019/12/18(水)18:03 ID:O+Yu98Ta(2/4) AAS
エラーの原因が一時的な要因（ネットワークエラー）によるものと
恒久的なもの（設定ファイル記述ミス）とで分ける仕組み無いかな
一時的なものならsystemdでリトライしてもらいたいが、
設定ミスとかリトライしたってしょうがないだろうと
324: 2019/12/18(水)18:13 ID:O+Yu98Ta(3/4) AAS
つーかリトライ上限すら無いんだな
325: 2019/12/18(水)21:07 ID:O+Yu98Ta(4/4) AAS
変数展開にExecStart=/bin/sh -cが広く使われてるワークアラウンドってのがダサいな
これのせいで絶対パス限定にした意味がなくなってるし
326: 2019/12/18(水)22:45 ID:OdcvQcja(1) AAS
まぁ、簡単にサービスを定義できるようになったから、逆にテキトウな設定で済ませてしまう（いわゆるコピペ）開発者やメンテナが増えてしまうっていうパターンだな。
RestartPreventExitStatus とか StartLimitBurst とかいろいろ仕組みはあるから…。
327: 2019/12/19(木)02:46 ID:JHq1dzG6(1) AAS
どこもかしこもsystemdってことは迎合してでも採用する利点があったってことじゃないの？
古来からの文法が刷新されて一から覚え直すハメになったのは分かるけど、
だからって開発者にまで批判ってどんだけ嫌われてるのコレ
Linux版のsvchost.exeってことで色々察したけどさ
swapも最近になって専用領域からファイルに変わったけどそこまでwindowsの後追いしなくてもなぁ
上下前次1-新書関写板覧索設栞歴
あと 675 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s