Raspberry Pi 起動時にfsck実行

## 序文
[Right way to fsck_repair root partition - Raspberry Pi Forums](https://forums.raspberrypi.com/viewtopic.php?t=245168#p1496151 "Right way to fsck_repair root partition - Raspberry Pi Forums")
> If a file named "fsck" is present in "/" then fsck will be run on boot before "/" is remounted read/write.
> so
> ```shell
> sudo touch /fsck
> ```
> and
> ```shell
> sudo reboot
> ```
> should be enough.

これは確かに`Linux`における昔からよく知られた方法。しかし`Raspberry Pi`環境で実行しても`fsck`は動いていないっぽい。ログファイルも`/var/log/fsck`配下に出力される筈だが、ディレクトリ自体存在しない。
自分もここら辺の理解がぼんやりしていて再確認してみたので備忘録として残す。

## 結論
起動システムによる。
- [init - Wikipedia](https://ja.wikipedia.org/wiki/Init "init - Wikipedia")
`UNIX`を始祖とする。この場合、冒頭の方法が正。
- [systemd - Wikipedia](https://ja.wikipedia.org/wiki/Systemd "systemd - Wikipedia")
上記`init`を置き換える目的として導入された。現在の`Debian`はこちらを採用していて、結果`Raspberry Pi OS`も同様。この場合は以下。
`/boot/cmdline.txt`に`fsck.mode=force`を追記し再起動。`systemd-fsck`サービスにより`fsck`が実行される。
```shell
pi@raspberrypi4:~ $ cat /boot/cmdline.txt
console=serial0,115200 console=tty1 root=PARTUUID=91029070-02 rootfstype=ext4 fsck.mode=force fsck.repair=yes rootwait video=HDMI-A-1:1280x720@60D
pi@raspberrypi4:~ $
```
最初から`fsck.repair=yes`が設定されていることが確認できる。これについて、起動時に必ず`fsck`をかける設定という説明を見かけたことがあるが間違い。これは`fsck`実行時の挙動を指定している。明示的に起動時に`fsck`実行の指定がなくても、システムが判断して実行される場合もあるからね。詳細は公式ドキュメント参照。

[systemd-fsck@.service(8) — systemd — Debian bullseye — Debian Manpages](https://manpages.debian.org/bullseye/systemd/systemd-fsck@.service.8.en.html "systemd-fsck@.service(8) — systemd — Debian bullseye — Debian Manpages")
> systemd-fsck understands these kernel command line parameters:
> 
> fsck.mode=
> 
> One of "auto", "force", "skip". Controls the mode of operation. The default is "auto", and ensures that file system checks are done when the file system checker deems them necessary. "force" unconditionally results in full file system checks. "skip" skips any file system checks.
> 
> fsck.repair=
> 
> One of "preen", "yes", "no". Controls the mode of operation. The default is "preen", and will automatically repair problems that can be safely fixed. "yes" will answer yes to all questions by fsck and "no" will answer no to all questions.

`systemd`関連のログは`journalctl`コマンドで確認するのが作法なので、`fsck`の場合も以下。
```shell
pi@raspberrypi4:~ $ journalctl -u systemd-fsck*
（中略）
 3月 09 21:37:51 raspberrypi4 systemd[1]: systemd-fsck@dev-disk-by\x2dpartuuid-91029070\x2d01.service: Succeeded.
 3月 09 21:37:51 raspberrypi4 systemd[1]: Stopped File System Check on /dev/disk/by-partuuid/91029070-01.
 3月 09 21:37:51 raspberrypi4 systemd[1]: systemd-fsck-root.service: Succeeded.
 3月 09 21:37:51 raspberrypi4 systemd[1]: Stopped File System Check on Root Device.
 3月 09 21:37:51 raspberrypi4 systemd[1]: systemd-fsck-root.service: Consumed 3.084s CPU time.
-- Boot d69fb2cf1ae1445aa7b1876e30d275b0 --
 3月 09 21:37:51 raspberrypi4 systemd-fsck[152]: e2fsck 1.46.2 (28-Feb-2021)
 3月 09 21:37:51 raspberrypi4 systemd-fsck[152]: Pass 1: Checking inodes, blocks, and sizes
 3月 09 21:37:52 raspberrypi4 systemd-fsck[152]: Pass 2: Checking directory structure
 3月 09 21:37:54 raspberrypi4 systemd-fsck[152]: Pass 3: Checking directory connectivity
 3月 09 21:37:54 raspberrypi4 systemd-fsck[152]: Pass 4: Checking reference counts
 3月 09 21:37:54 raspberrypi4 systemd-fsck[152]: Pass 5: Checking group summary information
 3月 09 21:37:54 raspberrypi4 systemd-fsck[152]: rootfs: 111962/450560 files (0.1% non-contiguous), 1248929/1792000 blocks
 3月 09 21:37:54 raspberrypi4 systemd[1]: Finished File System Check on Root Device.
 3月 09 21:37:56 raspberrypi4 systemd[1]: Starting File System Check on /dev/disk/by-partuuid/91029070-01...
 3月 09 21:37:56 raspberrypi4 systemd-fsck[345]: fsck.fat 4.2 (2021-01-31)
 3月 09 21:37:56 raspberrypi4 systemd-fsck[345]: /dev/sda1: 289 files, 61052/516188 clusters
 3月 09 21:37:56 raspberrypi4 systemd[1]: Finished File System Check on /dev/disk/by-partuuid/91029070-01.
 3月 09 21:38:26 raspberrypi4 systemd[1]: systemd-fsckd.service: Succeeded.
 3月 09 21:38:26 raspberrypi4 systemd[1]: systemd-fsckd.service: Consumed 1.338s CPU time.
-- Boot 94c43597f9de4738860d5a408423591c --
```

一応`/var/log/syslog`から確認することも可能。
```shell
pi@raspberrypi4:~ $ grep -a "systemd-fsck*" /var/log/syslog
（中略）
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: e2fsck 1.46.2 (28-Feb-2021)
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: Pass 1: Checking inodes, blocks, and sizes
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: Pass 2: Checking directory structure
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: Pass 3: Checking directory connectivity
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: Pass 4: Checking reference counts
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: Pass 5: Checking group summary information
Mar  9 21:37:57 raspberrypi4 systemd-fsck[152]: rootfs: 111962/450560 files (0.1% non-contiguous), 1248929/1792000 blocks
Mar  9 21:37:57 raspberrypi4 systemd-fsck[345]: fsck.fat 4.2 (2021-01-31)
Mar  9 21:37:57 raspberrypi4 systemd-fsck[345]: /dev/sda1: 289 files, 61052/516188 clusters
Mar  9 21:38:26 raspberrypi4 systemd[1]: systemd-fsckd.service: Succeeded.
Mar  9 21:38:26 raspberrypi4 systemd[1]: systemd-fsckd.service: Consumed 1.338s CPU time.
```

`fsck`が実行されない通常起動時のログは以下。
```shell
pi@raspberrypi4:~ $ journalctl -u systemd-fsck*
（中略）
 3月 09 21:50:08 raspberrypi4 systemd-fsck[148]: e2fsck 1.46.2 (28-Feb-2021)
 3月 09 21:50:08 raspberrypi4 systemd-fsck[148]: rootfs: clean, 111964/450560 files, 1249005/1792000 blocks
-- Boot d69fb2cf1ae1445aa7b1876e30d275b0 --
 3月 09 21:50:08 raspberrypi4 systemd[1]: systemd-fsck@dev-disk-by\x2dpartuuid-91029070\x2d01.service: Succeeded.
 3月 09 21:50:08 raspberrypi4 systemd[1]: Stopped File System Check on /dev/disk/by-partuuid/91029070-01.
 3月 09 21:50:08 raspberrypi4 systemd[1]: systemd-fsck-root.service: Succeeded.
 3月 09 21:50:08 raspberrypi4 systemd[1]: Stopped File System Check on Root Device.
 3月 09 21:50:08 raspberrypi4 systemd[1]: systemd-fsck-root.service: Consumed 3.057s CPU time.
-- Boot 94c43597f9de4738860d5a408423591c --
 3月 09 21:50:10 raspberrypi4 systemd[1]: Starting File System Check on /dev/disk/by-partuuid/91029070-01...
 3月 09 21:50:10 raspberrypi4 systemd-fsck[339]: fsck.fat 4.2 (2021-01-31)
 3月 09 21:50:10 raspberrypi4 systemd-fsck[339]: /dev/sda1: 289 files, 61052/516188 clusters
 3月 09 21:50:10 raspberrypi4 systemd[1]: Finished File System Check on /dev/disk/by-partuuid/91029070-01.
 3月 09 21:50:40 raspberrypi4 systemd[1]: systemd-fsckd.service: Succeeded.
-- Boot 86674087b21d430184133809976e77d7 --
```

```shell
pi@raspberrypi4:~ $ grep -a "systemd-fsck*" /var/log/syslog
（中略）
Mar  9 21:50:07 raspberrypi4 systemd[1]: Requested transaction contradicts existing jobs: Transaction for wd_keepalive.service/start is destructive (systemd-fsck@dev-disk-by\x2dpartuuid-91029070\x2d01.service has 'stop' job queued, but 'start' is included in transaction).
Mar  9 21:50:07 raspberrypi4 systemd[1]: watchdog.service: Failed to enqueue OnFailure= job, ignoring: Transaction for wd_keepalive.service/start is destructive (systemd-fsck@dev-disk-by\x2dpartuuid-91029070\x2d01.service has 'stop' job queued, but 'start' is included in transaction).
Mar  9 21:50:11 raspberrypi4 systemd-fsck[148]: e2fsck 1.46.2 (28-Feb-2021)
Mar  9 21:50:11 raspberrypi4 systemd-fsck[148]: rootfs: clean, 111964/450560 files, 1249005/1792000 blocks
Mar  9 21:50:11 raspberrypi4 systemd-fsck[339]: fsck.fat 4.2 (2021-01-31)
Mar  9 21:50:11 raspberrypi4 systemd-fsck[339]: /dev/sda1: 289 files, 61052/516188 clusters
Mar  9 21:50:40 raspberrypi4 systemd[1]: systemd-fsckd.service: Succeeded.
```
※ USB-SSDからの起動環境なので、`microSD`からの起動と内容は少し異なるので注意

そうそう、`systemd`環境で`sudo touch /fsck`実行、再起動すると以下のログが出力されるんだよな。`fsck.mode=force`を指定しなさいと。
```shell
 3月 08 20:58:48 raspberrypi4 systemd-fsck[141]: Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system.
```

## 我が闘争@systemd
今となっては`systemd`が主流になった感があり、`Linux`起動システムといえば`systemd`、初めて触れたディストリビューションがそうだった、という人も多いかもしれない。
ぐぐると`systemd`を解説したページも多数ヒットする。`Linux`起動の仕組みを理解するにはまず`systemd`という感じ。

しかし歴史的経緯として、`init`を置き換える目的で`systemd`が導入されたのは約10年前で、当時かなり揉めたらしい。

[Linus Torvalds and others on Linux's systemd](https://www.zdnet.com/article/linus-torvalds-and-others-on-linuxs-systemd/ "Linus Torvalds and others on Linux's systemd _ ZDNet")
> LinuxまたはUnixの開発者でない場合は、新しいLinux固有のシステムおよびサービスマネージャーであるsystemdについて聞いたことがありません。ただし、Linux開発者サークルでは、UnixとLinuxの従来のsysvinitデーモンのこの置き換え以外に、多くのプログラマーを怒らせるものはありません。

[systemd - Wikipedia](https://ja.wikipedia.org/wiki/Systemd "systemd - Wikipedia")
> systemdの設計はフリーソフトウェアコミュニティにおける重要な論争の元となった。これはsystemdのアーキテクチャはUNIX哲学に反しており最終的に相互依存でがんじがらめの塊を作ってしまうと批評家達を主張させるようになっているためである[7]。しかしながら2015年現在、主要なLinuxディストリビューションのほとんどはsystemdをデフォルトのinitシステムとして採用している。

`Debian`が`systemd`を採用したのは2015年4月25日、Debian8.0(jessie)から。そして、10年前と言えば`Raspberry Pi`が発売された年。当時の`Raspbian`って何だっけ？ と思い確認。
[RaspbianFAQ](https://www.raspbian.org/RaspbianFAQ "RaspbianFAQ - Raspbian")
> #### What is Raspbian?
> Raspbian is an unofficial port of Debian wheezy armhf with compilation settings adjusted to produce code that uses "hardware floating point", the "hard float" ABI and will run on the Raspberry Pi.

このページ、懐かしいね。それはさておき、最初の`Raspbian`は`Debian wheezy`ベースだったということは、バーション番号で言えば`7.0`、`sysytemd`対応直前、まだ`init`だったということになる。
ここら辺が混乱の元、変に（？）`Linux`歴が長い人や最初期から`Raspberry Pi`に触れている人の中には今でも`sudo touch /fsck`方式が正と思い込んでいる人がいる、という状況なのかも。

参考URL：
[Index of _pub_raspberrypi_raspbian_images](http://ftp.jaist.ac.jp/pub/raspberrypi/raspbian/images/ "Index of _pub_raspberrypi_raspbian_images")
最古の`Raspbian`イメージ、`wheezy`版が確認できる。

## Debian wheezy
実は手元に化石環境、`Debian wheezy`インストールデスクトップPC があり、丁度再最近`sudo touch /fsck`で`fsck`をかけたので再確認したところ`/var/log/fsck`配下にログが確認できた。確かにこれは`init`の挙動。

```shell
root@epiam10000:~# cat /var/log/fsck/checkfs
Log of fsck -C -R -A -a
Fri Mar 11 21:35:30 2022

fsck from util-linux 2.20.1
/dev/sda1: clean, 240/124496 files, 32433/248832 blocks

Fri Mar 11 21:35:30 2022
----------------
root@epiam10000:~# cat /var/log/fsck/checkroot
Log of fsck -C -a -t ext4 /dev/debian/root
Fri Mar 11 21:35:27 2022

fsck from util-linux 2.20.1
/dev/mapper/debian-root: clean, 157301/49987584 files, 180026135/199928832 blocks

Fri Mar 11 21:35:27 2022
----------------
root@epiam10000:~#
```

## Devuan 4.0（Devuan Chimaera）
いずれにしても昔の話じゃん、という声もあるかもしれないが、今でも`systemd`に移行していないディストリビューションはあるし、`Debian`にしてもその件で分裂して`Devuan`がフォークされている。
[2015年4月7日　Debian 8が間もなくリリース，どう出る _Devuan_？](https://gihyo.jp/admin/clip/01/linux_dt/201504/07 "2015年4月7日　Debian 8が間もなくリリース，どう出る _Devuan_？：Linux Daily Topics｜gihyo.jp … 技術評論社")
> DebianのバージョンアップはUbuntuなどDebianをペアレントとする多くのディストリビューションに影響を与えることになるが，そんな中でLinux界隈の一部ではDebianからフォークしたその名も「Devuan」のリリースに注目が集まっている。
> 
> Devuan（Dev-Oneと発音する）は，Jessieからはデフォルトの起動システムにsystemdを採用するとしたDebianの決定に反対したメンバーがDebianからフォークし，新たに立ち上げたプロジェクトだ。「⁠systemdの依存性の強さはディストリビューションとしての自由度を損ねる」としてDebian本体と決別，最初の安定版のリリースを目指して開発が行われている。

[Welcome to devuan.org](https://www.devuan.org/ "Welcome to devuan.org _ Devuan GNU+Linux Free Operating System")
> Devuan GNU+Linux is a fork of Debian `without systemd` that allows users to reclaim control over their system by avoiding unnecessary entanglements and ensuring Init Freedom.
> Devuan GNU + Linuxは、`systemdを使用しない`Debianのフォークであり、ユーザーが不要な絡み合いを回避し、Init Freedomを確保することで、システムの制御を取り戻すことができます。

どんだけ`systemd`が嫌なんだよというね（笑）。しかし`Devuan`は現在も`Debian`系の軽量ディストリビューションとして一定の評価は受けているという認識。
前から気になっていたので今回確認したところ、`Debian Bullseye`相当の最新版 4.0 がリリースされていてびっくり。

[Release Information _ Devuan GNU+Linux Free Operating System](https://www.devuan.org/os/releases "Release Information _")

[仮想PC用イメージ](https://www.osboxes.org/devuan-linux/ "Devuan Linux VM images for VirtualBox and VMware")も公開されていたので、`VirtualBox`に入れてみた。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/254888/868f8c41-f982-645d-5dc0-84575e3ff6f2.png" width=80%>
うーん、確かにこれは`init`の挙動。起動も速いし軽量。しかし実際のところどうなんだろう。起動システムが違うだけでユーザランドは`Debian`と同じだろうし。ライトユーザには起動システムなんて関係ないような……。

## 我が闘争@Linux
`systemd`での分裂で思い出したのが`ffmpeg`。これも10年程前の話。

[本の虫_ ffmpegとlibavの背景事情](https://cpplover.blogspot.com/2012/03/ffmpeglibav.html "本の虫_ ffmpegとlibavの背景事情")
> 2012-03-27
> #### ffmpegとlibavの背景事情
> ffmpegをインストールしようとしたら、なにやらちょうど一年前あたり、大規模なforkが起こったらしい。いまや、ffmpegとlibavに分裂している。forkは自由なソフトウェアではいたって普通の出来事だ。大抵の場合、開発者の間での意見の不一致により起こる自然な現象だ。自由なソフトウェアであれば、fork自体はそれほど悪いことではない。どちらも自由であるので、双方の開発者がIRCやMLで広角泡を飛ばしながら喧嘩しつつ、何事もなかったかのように相手のコードをこちらのコードベースにマージできる。なぜならば、どちらも自由なソフトウェアという共通点を持っているからだ。

[GNOME](https://ja.wikipedia.org/wiki/GNOME "GNOME - Wikipedia")や[Mono](https://ja.wikipedia.org/wiki/Mono_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2) "Mono (ソフトウェア) - Wikipedia")で知られる[ミゲル君](https://ja.wikipedia.org/wiki/%E3%83%9F%E3%82%B2%E3%83%AB%E3%83%BB%E3%83%87%E3%83%BB%E3%82%A4%E3%82%AB%E3%82%B6 "ミゲル・デ・イカザ - Wikipedia")の投稿が話題になったのも10年前だったね。

[何がLinuxデスクトップを殺したか（What Killed the Linux Desktop 日本語訳）](https://www.yamdas.org/column/technique/linuxdesktopj.html "何がLinuxデスクトップを殺したか（What Killed the Linux Desktop 日本語訳）")
> 我々にもチャンスはあった。最大のチャンスは、Vista が市場でコケたときだ。なのに我々は内部闘争に明け暮れていた。その頃の自分たちがやっていた争いについて書いている人もいる。

`Linux`界隈っていつも揉めてるよな。これがフリーソフト、オープンソースという名の桃源郷の現実。といういか、民主主義の常か。
こうした古（いにしえ）のテキストを読み返していると思い出すのが`OpenSSL is written by monkeys`。
今回再確認したらオリジナルは消滅していた。しかし大丈夫、`github`に日本語翻訳版がアップされている。これが集合知の力ですよ（誤用）。

[OpenSSL はサルが書いたに決まってる (OpenSSL is written by monkeys, by Marco Peereboom)](https://gist.github.com/euske/cf40ff33994e2339cfd24a76fe977b55 "OpenSSL はサルが書いたに決まってる (OpenSSL is written by monkeys, by Marco Peereboom) · GitHub")
> 俺の結論はこうだ。OpenSSL はこれまで書かれてきた中でもダントツで 史上最悪のライブラリである。これはまさにサルが壁にウンコを投げつけているに等しい。 俺はいまだに全世界のインターネットがこのアホらしく複雑かつウンコな 「OpenSSLプロジェクト」とか呼ばれるコードの上で走っているのが信じられない。

10年近く前、`OpenSSL`の脆弱性[ハートブリード](https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%BC%E3%83%88%E3%83%96%E3%83%AA%E3%83%BC%E3%83%89 "ハートブリード - Wikipedia")が大問題になったけど、その数年前に`OpenSSL`の実装がいかに汚いか告発していた人が居たということで話題になったという経緯がある。
それにしても、今読み返しても普通に面白。`Day 1`、`Day 2`ってのは英語での常套表現らしいけど、それが利いてるよな。ストーリー性があり味わいを増している。

因みに約20年程前、`24 -TWENTY FOUR-`というアメリカのTVドラマが大ヒットしたけど、ファンの間ではシーズンのことを`Day1`、`Day2`なんて表現する、なんて話もあったね。
[24 -TWENTY FOUR- - Wikipedia](https://ja.wikipedia.org/wiki/24_-TWENTY_FOUR- "24 -TWENTY FOUR- - Wikipedia")
> アメリカのメディアやファンの間では、1つのストーリーが24時間で完結することから「シーズン（Season）」のことを「デイ（Day）」と表現する事がある（Day1、Day2……）。

`Internet Archive`からオリジナルページを発掘。2020年頃に消滅した模様。
[Flingpoo!](https://web.archive.org/web/20201224212934/https://www.peereboom.us/assl/assl/html/openssl.html "Flingpoo!")

話が脱線しまくりだけど、前述の通り、丁度10年前が`Raspberry Pi`発売の年だった。10年前を振り返ってみるもアリでは。

## 余談
[【 fsck 】コマンド――ファイルシステムを検査、修復する：Linux基本コマンドTips（191） - ＠IT](https://atmarkit.itmedia.co.jp/ait/articles/1803/15/news040.html "【 fsck 】コマンド――ファイルシステムを検査、修復する：Linux基本コマンドTips（191） - ＠IT")
> ファイルシステムに応じてそれぞれ/sbinなどにある専用のコマンドを呼び出しています。

公式ドキュメントにも関連項目として各ファイルシステムに対応したコマンドが挙げられている。

[fsck(8) — manpages-ja — Debian bullseye — Debian Manpages](https://manpages.debian.org/bullseye/manpages-ja/fsck.8.ja.html "fsck(8) — manpages-ja — Debian bullseye — Debian Manpages")
> 関連項目
fstab(5), mkfs(8), fsck.ext2(8) または fsck.ext3(8) または e2fsck(8), cramfsck(8), fsck.minix(8), fsck.msdos(8), fsck.jfs(8), fsck.nfs(8), fsck.vfat(8), fsck.xfs(8), fsck.xiafs(8), reiserfsck(8).

改めて眺めていて気になったのが二つ。
まず一つ目が`fsck.nfs`。`NFS`の修復なんてできるの？ とリンク先を確認。

[fsck.nfs(8) — initscripts — Debian bullseye — Debian Manpages](https://manpages.debian.org/bullseye/initscripts/fsck.nfs.8.en.html "fsck.nfs(8) — initscripts — Debian bullseye — Debian Manpages")
> #### 名前
> fsck.nfs-常に成功を返すダミーのfsck.nfsスクリプト。
> #### 説明
> Debian GNU / Linuxは、ルートファイルシステムがNFS上にある場合にこれを必要とします。ルートがNFSマウントされているかどうかを確認する方法はなく、本当に「fsck-a/」を実行したいと考えています。

なるほどねぇ。
そして二つ目が`fsck.minix`。`MINIX`のクローンとして出発したのが`Linux`。という歴史の1ページが垣間見えるね。

関連投稿：
[ひねくれ者の Linux _ PC 談義 - Qiita](https://qiita.com/god19/items/504cde42d405dac3c479 "ひねくれ者の Linux _ PC 談義 - Qiita")

## 参考URL
[Raspberry Pi4の不要なサービス・ハードの停止 _ WordPressをRaspberryPi4で始める方法](http://www.momobro.com/rasbro/tips-rp-raspberry-pi-stop-service/ "Raspberry Pi4の不要なサービス・ハードの停止 _ WordPressをRaspberryPi4で始める方法")
[第545回　systemdのログ「ジャーナル」を見る・ためる：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社](https://gihyo.jp/admin/serial/01/ubuntu-recipe/0545 "第545回　systemdのログ「ジャーナル」を見る・ためる：Ubuntu Weekly Recipe｜gihyo.jp … 技術評論社.html")
[systemd_ジャーナル - ArchWiki](https://wiki.archlinux.jp/index.php/Systemd/%E3%82%B8%E3%83%A3%E3%83%BC%E3%83%8A%E3%83%AB "systemd_ジャーナル - ArchWiki")
[journalctlコマンド - systemd管理のログを見る - Ubuntuサーバー構築入門 - Ubuntuサーバーでゼロから環境構築](https://ubuntu.perlzemi.com/blog/20200602135100.html "journalctlコマンド - systemd管理のログを見る - Ubuntuサーバー構築入門 - Ubuntuサーバーでゼロから環境構築")
[【初級者向け】Linuxシステムの起動 ～ SysVinit、Upstart、systemd ～ _ TECH PROjin](https://tech.pjin.jp/blog/2020/11/11/linux-system-boot-2 "【初級者向け】Linuxシステムの起動 ～ SysVinit、Upstart、systemd ～ _ TECH PROjin")
[なぜsystemdなのか？ _ POSTD](https://postd.cc/why-systemd/ "なぜsystemdなのか？ _ POSTD")
[最低限知っておきたいsystemctlとjournalctlの使い方](https://www.karakaram.com/how-to-use-systemctl-journalctl/ "最低限知っておきたいsystemctlとjournalctlの使い方 - karakaram-blog")
[systemd超入門 _ DevelopersIO](https://dev.classmethod.jp/articles/systemd-getting-started/ "systemd超入門 _ DevelopersIO")
[これからSystemd入門する - Qiita](https://qiita.com/bluesDD/items/eaf14408d635ffd55a18 "これからSystemd入門する - Qiita")