Fedora 41 をインストールしました。前回に引き続き kickstart を使用したアップグレードインストールです。

Fedora 40 からの非互換あれこれ

いくつか非互換がありましたが、今回は前向きな仕様変更で、以前からの宿題が解決しました。

DNF5 へ移行

Fedora 41 から DNF5 に切り替わりました。キビキビと動いて、消費メモリも従来と違って抑えられているので快適に使えます。

自動的にアップデートしたい場合は、dnf5-plugin-automatic をインストールします。このパッケージには、当初、設定ファイルのサンプルが入っておらず、 「いくらなんでもそりゃひでーだろ」って文句付けたら、入れてもらえることになりました。 が、設定ファイルの置き場である /etc/dnf/dnf5-plugins/automatic.conf ではなく、/usr/share/dnf5/dnf5-plugins/automatic.conf に入っています。なぜこうした?

設定する場合は、以下のようにデフォルトの設定ファイルをコピーして編集するか、

# cp /usr/share/dnf5/dnf5-plugins/automatic.conf /etc/dnf/dnf5-plugins/automatic.conf
#

/etc/dnf/dnf5-plugins/automatic.conf にデフォルトと違う設定だけを書きます。設定の反映順としては、以下の順になります。

  1. /etc/dnf/dnf5-plugins/automatic.conf
  2. /usr/share/dnf5/dnf5-plugins/automatic.conf
  3. ハードコードされた設定

dnf5-plugin-automatic には、以下のように、アップデート後に自動再起動する設定が新設されました。

# When the system should reboot following upgrades:
# never                              = don't reboot after upgrades
# when-changed                       = reboot after any changes
# when-needed                        = reboot when necessary to apply changes
reboot = never

# The command that is run to trigger a system reboot.
reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

この「再起動が必要かどうかの判定」については別に記事を書きましたが、精度がイマイチなのと、サービスの再起動まで含めると面倒臭いので、when-changed(更新がインストールされた場合は内容に関わらず再起動)を採用しています。再起動用のコマンドも指定できるので、必要に応じて調整可能です。

dnf5-automatic-notifyonly.service(通知のみ)や dnf5-automatic-install.service(自動インストール実行)は提供されなくなったので、/usr/local/lib/systemd/system に自分で作ります。

# mkdir -p /usr/local/lib/systemd/system
# sed '/^ExecStart=.*$/ s/$/ --no-downloadupdates/' \
      /usr/lib/systemd/system/dnf5-automatic.service \
          > /usr/local/lib/systemd/system/dnf5-automatic-notifyonly.service
# cp /usr/lib/systemd/system/dnf5-automatic.timer \
          /usr/local/lib/systemd/system/dnf5-automatic-notifyonly.timer
# sed '/^ExecStart=.*$/ s/$/ --installupdates/' \
      /usr/lib/systemd/system/dnf5-automatic.service \
          > /usr/local/lib/systemd/system/dnf5-automatic-install.service
# cp /usr/lib/systemd/system/dnf5-automatic.timer \
          /usr/local/lib/systemd/system/dnf5-automatic-install.timer
# 

私の運用では、通知のみの日と、自動インストールの日が分かれているので、どうしても両方欲しいんです。dnf5 automatic コマンドのオプションとしては、以下の 4つが用意されているので、必要なものを適宜設定しましょう。

  • --downloadupdates
  • --no-downloadupdates
  • --installupdates
  • --no-installupdates

--downloadupdates--no-installupdates の違いがよくわかりませんが、このようになっています。

ともあれ、設定項目も従来と同じですし、ちょっとしたことで従来通りの運用は可能でした。

systemd 256

systemd 256 から systemctl edit--stdin オプションが追加され、 非インタラクティブエディタが使えるようになりました(公式の説明)。何のこっちゃ? という感じですが、 このオプションは、標準入力から設定を渡して、設定を自動化したい時に有用です。

# cat << EOF | systemctl edit --stdin dnf5-automatic-notifyonly.timer
[Timer]
OnCalendar=
OnCalendar=Mon..Sat *-*-* 6:00
RandomizedDelaySec=60m
EOF
Successfully installed edited file '/etc/systemd/system/dnf5-automatic-notifyonly.timer.d/override.conf'.
#

こんな感じで、標準入力から流し込んだデータを使って設定できます。同じことは、以前から、以下のようにやればできたと言えばできたのですが、+4 という要らないファイルが作られてしまいます。

# cat << EOF | SYSTEMD_EDITOR=tee systemctl edit dnf5-automatic-notifyonly.timer
...

これは以下のように、子プロセスとして実行される vim に 4行目にカーソルを移動させるコマンドライン引数が渡されるためです。

vim +4 /etc/systemd/system/dnf5-automatic-notifyonly.timer.d/override.conf

SYSTEMD_EDITORtee を指定すると、+4 という要らないファイルが作られます。

tee +4 /etc/systemd/system/dnf5-automatic-notifyonly.timer.d/override.conf

今回のバージョンアップで SYSTEMD_EDITOR の設定も不要になって、便利になりました。

setproctitle() が効かない

Python モジュールの障害です。pip からインストールした setproctitle() が効かないという事象が発生しました。 特にエラーとかは出ないのですが、テストコードをデバッグモードで動かしてみると、ちゃんとインストールされてない感じです。

$ SPT_DEBUG=1 python3 test.py
DEBUG:setproctitle:failed to import setproctitle: cannot import name '_setproctitle' from partially initialized module 'setproctitle' (most likely due to a circular import) (/usr/local/lib/python3.13/site-packages/setproctitle/__init__.py)
DEBUG:setproctitle:setproctitle C module not available
DEBUG:setproctitle:setproctitle C module not available
test.py
$ 

pip からインストールするのはやめて、dnf5 から python3-setproctitle をインストールすることにしました。こちらはちゃんと動きます。

アップグレードインストール時にファイルのオーナーがおかしくなる

これは Fedora 41 の話ではなく、前回からの宿題です。Kickstart でアップグレードインストール(/home だけ残して残りは全部インストールし直すので、アップグレードという言い方はちょっと変ですが)すると、/home 以下のオーナーがおかしくなる、という問題が発生していました。

結論から言うと、アップグレード前後で、UIDGID を一致させる必要がありました。 /home 以下のファイルの UIDGID は予め設計しておけ、ということですね。 Kickstart でインストールした時点で当該のユーザ/グループが存在する必要はなく、 初回起動後以降、いつでもよいので UIDGID を指定して、所望のユーザを作れば OK でした。 もちろん、Kickstart で作っても OK です。

その他雑感

全体として高速になったそうですが、サーバとして遠隔で使っているので私個人としてはあまり実感はありません。メモリ使用量の推移を見ていると、各プロセスの RSS(Resident Set Size)が Fedora 40 に比較して多めになっている感じがします。スワップ側へ逃がすタイミングを調整しているのでしょうか。

Fedora に移行して 3年経ちましたが、安定していますし標準レポジトリが充実しているため、追加レポジトリが不要で運用上のトラブルがなく快適です。 Cent OS を使っていた頃の方が私のやりたいことと合わずに問題を抱えていたように思います。 半年に一回、見直しとリフレッシュするのは、むしろ変な設定とかをバージョンアップに追随できない粗悪なソフトウェアをあぶり出せて良い感じがします。 企業の情報システムは長期サポートを前提にしていますが、その考えを改めて、OS を Fedora に指定する方が、 技術力のない粗悪なベンダー除けになるかもしれませんよ?