amazon linux2のデフォルトサービスが色々増えたり変わったりしてて顔面が真っ青になったので再び調べたりして再セットアップ
起動しなくなったりしても恨まないように
その場合クラウドだし投げ捨ててあたらしくつくろう
$ sudo su -
$ ntsysv
network
クラウドでネットワークが要らないケースはそんなに無いんじゃなかろうか
というわけで続投
acpid.service
電源管理デーモン(主にノーパで活躍しているらしい)
クラウドによっては切ってはいけんらしいが、ec2でやる分には
・コマンドからのreboot
・AWSコンソールからのreboot/stop・start/terminate
両方普通にいけるので切り
amazon-ssm-agent.service
aws ssm利用予定は現在のところ無いので切り
atd.service
とある時にatコマンド何度か使ったことあるので続投
auditd.service
システムコールの監視してくれてる
ログ出力先のデフォルトは /var/log/audit/audit.log
amazon linux2だとデフォルトでonになってる(前まで -a never,task って入ってたはず)
これパフォーマンス影響があるかもよって言われ続けてたけど、デフォルトで入ってるならAWSはいけると判断したんだろうきっと
selinux使わんでもメリットあると思うんで続投
(ちなみにselinuxはデフォルトオフ)
chronyd.service
時刻同期のアレ 続投
cloud-*
ec2が起動するときってcloud-initとかそういう連中が動いてるはずで、そいつらに関与すんのかね
ちゃんと調べればいらないやつもいるのかもしれないけどとりあえず続投で
各サービスの役割を知ってる人がいたらそっと教えてください
crond.service
大体使うので続投
dm-event.socket
うーん。device mapperイベントを監視してるんかなこいつは。
lvm/dockerを利用しないんであれば要らないと思うんだけど、要る場合でもこいつが起きている必要があるのかがなんともわからん
とりあえずはlvmやdockerを利用する予定のないインスタンスでは切ろうかと思う
dmraid-activation.service
RAID関連
まあ要らないよね
hibinit-agent.service
インスタンスの「休止」をサポートするためのagentっぽい
停止と休止はRAMに乗っかってるものを、停止は単に揮発するけど休止の場合はルートボリュームにファイルとして保持するのが違いなようだ
インメモリデータストアとかをEC2にのっけて使ってる場合は使えそう？
基本使う予定ないので切り
irqbalance.service
通常linuxカーネルは割り込み処理をcpu0でのみ処理するが、こいつが有効になってれば各cpuに負荷を分散してくれるらしい
そのためコア1のインスタンスでは意味を成さない
繊細な設定が要件として必要でないなら続投のままでよさそう
libstoragemgmt.service
外部ストレージアレイを管理してくれるらしい
クラウドでこいつが生きてないと困る状態ってすんごい特殊というか、あるんだろうか
まあ切り
lvm2-*
libstoragemgmtとは違ってこいつらは論理ボリュームをホニャララする連中
lvmを利用する想定がないなら要らないはず
dm-eventと同じく、切ったときにdockerに何か影響があるのかはまるでわからん
よって同じ理由により切り
mdmonitor.service
RAIDの監視ツールなようだ
dmraid切ってんだしこいつも要らんだろう
postfix.service
自前メールサーバ環境構築とかもうやりたくないです
切り
rngd.service
乱数ジェネレータ
何をするインスタンスなのかにも寄るけど切るメリットもそんな無さそうなので続投
rpcbind.service/socket
RPCプログラム番号をポートにマッピングする機能
gRPCとかやるときは必要になる気がするけど今回は必要ないので切り
NFSv3以前はこいつが必須だったようだけどv4でもういらなくなったそうなのでnfs使う場合でも要らないっぽい
rsyslog.service
ログ管理
これだけで記事になるくらい濃い
minimalｲﾝｽｺでも入るようなナイスガイを切る勇気はないので続投
sshd.service
切っちゃあかんやろ
sysstat.service
リソースの状態を保存したり整形したり見られるようになったりするサービス
sa1とかsa2とかそういうやつ(sa1・sa2は/etc/cron.d/sysstatにバリバリ書いてある、デフォルトは10分に1回で23:53にレポート作る)
ec2のリソース監視をどんな形でやっていくかっていう監視設計の話になってくるので要るなら生かして要らないなら切ろう
systemd-readahead-collect/drop/replay
collectで起動時の情報を記録
replayで次回起動時にその記録された情報を再生(前回記録から、どうせ読むことが分かっているデータを先に読んじゃって起動時間を早めるんだとか)
dropはシステムに更新が入ったときに集めた情報を吹っ飛ばすらしい。
切るメリットもそんなに無いけどサーバ用途ならそんなしょっちゅう落としたりなんだりしないだろうからなんとも微妙な…
とりあえずこれがonの状態で困ってはいないので残しておくか…
update-motd.service
ログインしたときに出るアレの内容をupdateしてるおじさん
個人的に生きてる方がありがたいので(5.1:4.9くらいだけど)続投
設定終わったらrebootコマンド叩く。
で、systemctl list-unit-files --type=service | grep enabled あたりで確認。
enabledでgrepかけないときに出てくるstaticってなってるやつはおいそれと手を出すと不幸になりそう
autovt@とgetty@ってやつがおる場合、まあ止めないでおきましょう。
autovt@は確かGUIが死んじゃってどうもならんときにプロンプト呼ぶやつで、getty@はユーザログイン(認証)とか制御してるおじさんって認識なので両方切ったところでec2だし問題ないんでは…？と思いもするんだけど…
これも詳しい人いたらそっと教えてください
あとは従来通り違うユーザ作ったりsyslog設定したりec2-user消したりして遊ぼう
ami化して使いまわす場合は、デフォルトだと /etc/cloud/cloud.cfg の効果でec2-userが起動時に作り直されてしまうので
users-groups をコメントアウトしておこうな
追記
microcode.service
CPUに対するパッチをOS起動時にあててくれるナイスガイなようなので止める理由なし