「Linuxサーバーを立ち上げたはいいけど、毎回手動でWebサーバー（Nginxとか）を起動するのが面倒！」
「毎日決まった時間に、データベースのバックアップを自動で実行させたいんだけど…？」
ある日突然、あなたのLinuxサーバーがそんな状態になって、スマホで慌てて「linux 自動起動」とか「linux 定期実行」なんて検索して、このページにたどり着いてくれたんじゃないでしょうか。
もしかして、「systemd」と「cron」っていう言葉は聞いたことあるけど、「この2つって、結局何が違うの！？」って、もう途方に暮れていたり…？
「linux 起動時 コマンド実行」って、どうやるのが正解なの…？って、もうパニックになっちゃいますよね😥
わかります、わかります！私も全く同じ経験があります。
サーバー管理って、こういう「自動化」の設定でつまずくと、一気に全部が面倒になっちゃうんですよね。
でも、大丈夫です！
その焦る気持ち、よーくわかります。でも、慌てて設定ファイルを闇雲にいじるのは、絶対に待ってください！
これらの「自動起動」や「定期実行」は、2つの仕組みの役割さえ理解しちゃえば、ぜんぜん難しくないんです。ハードウェアの故障なんかとは違いますからね！😮
この記事は、そんな「Linux自動化の壁」にぶつかってしまったあなたを救うための、安全な対処法をステップバイステップで徹底的に解説する「完全ガイド」です🕵️♀️✨
「systemd (systemctl)」を使ったOS起動時のサービス自動起動から、「cron (crond)」を使った指定時間のタスクスケジューリングまで。
この記事を読み終わる頃には、「linux サービス一覧」の確認方法、「linux ジョブ 確認」のテクニック、さらには「linux ランレベル（systemdのtarget）」や「linux reboot」「linux レスキューモード」といった関連知識まで、体系的にマスターできているはずです！
私と一緒に、一つずつ冷静に確認していきましょうね😍
systemd と cron：Linux自動実行の2大巨頭
まず最初に、多くのLinux初学者の人が混乱しがちな、「systemd」と「cron」の役割分担を、はっきりとさせておきましょう！
この2つは、「やりたいこと（目的）」がぜんぜん違うんです。
だから、どちらが優れているっていうお話じゃなくて、やりたいことに合わせて正しく使い分ける必要があるんですね。
systemd (System Management Daemon) の役割
「systemd」は、現代のLinux（RHEL/CentOS 7以降, Debian 8以降, Ubuntu 15.04以降など）における、もう「標準」と言っていい「initシステム」です。
initシステムっていうのは、Linuxカーネルが起動した後に、システム全体を「使える状態」にするために、いろんなプログラム（サービス）を順番に立ち上げたり、管理したりする、すっごく基本的な（PID 1の）プロセスのことを指します。
systemdの主な役割は、ズバリ「サービス管理」です！
- OS起動時のサービス自動起動: OSが起動するのと同時に、Webサーバー(nginx)やデータベース(MySQL)みたいな「サービス」を自動で立ち上げてくれます。
- サービスの依存関係管理: 「ネットワークが有効になってからDBを起動して、DBが起動してからWebアプリを起動する」みたいな、複雑な起動の順番もしっかり管理してくれるんです！
- サービスの監視と自動再起動: もしサービスが何らかの理由で異常終了しちゃっても、自動で再起動させてくれる機能（監視）も持っています。
- システム状態の管理: OSのシャットダウンや、再起動（linux reboot）、あるいは緊急時の「linux レスキューモード」への移行なんかも、全部systemdが管理してるんですよ。
「linux サービス」の自動起動や管理（linux 自動起動）について考えたいな…って思ったら、まず真っ先に参照すべきは、この「systemd」なんです！
cron (crond) の役割
一方、「cron」（実行デーモンは crond）は、systemdよりもずーっと古くから使われている、とってもシンプルな「タスクスケジューラ」です。
cronの役割は、たった一つ！
「指定された”時間”に、指定された”コマンド”を実行する」こと。
- 定期的なタスク実行: 「毎日深夜3時にバックアップスクリプトを実行する」とか、「5分ごとにサーバーの死活監視コマンドを実行する」みたいな用途に、もうピッタリなんです。
- 時間ベースのトリガー: cronは、OSの起動状態とか、サービスの依存関係なんて一切気にしません！（ここがsystemdと全然違うところ！）ただひたすら「時間」をキッカケ（トリガー）にして動くんですね。
「決まった時間に何かを実行したい！」っていう、その「linux 定期実行」のニーズには、cronを使いましょう！
どちらを使うべきかの判断基準
もうわかりましたよね？
▼「OSの起動と同時に、ある”状態”を維持したい」（例：Webサーバーを常に起動させておきたい）
→ systemd を使います。
▼「特定の”時間”が来たら、一回だけ処理を実行したい」（例：毎晩バックアップを取りたい）
→ cron を使います。
この基本的な違いをしっかり理解した上で、それぞれの具体的な使い方を、さっそく見ていきましょう！
【systemd編】サービスの自動起動と管理（linux サービス）
systemdを操作するためのメインのコマンドが、「systemctl」です。
これ、もう絶対仲良くなっておかないといけないコマンドですよ！
systemdは、「ユニット（Unit）」っていう”かたまり”で、管理する対象を扱います。
その中でも、私たちが一番よく使うのが、サービスを定義するための「サービスユニット（.service ファイル）」なんです。
サービスの自動起動を設定する (enable / disable)
サーバーを再起動（linux reboot）した後も、勝手にサービスが起動してほしい！
そう設定するためには、「enable」サブコマンドを使います。
▼ サービスの自動起動を有効にする
sudo systemctl enable [サービス名].service
（例：nginxの自動起動を有効にする）
sudo systemctl enable nginx
（「.service」は省略できることが多いですよ）
これを実行すると、systemdは「OK！次回のOS起動時から、このサービスを自動で起動するね！」って、設定をちゃんと記憶してくれます。
▼ サービスの自動起動を無効にする
sudo systemctl disable [サービス名]
（例：nginxの自動起動を無効にする）
sudo systemctl disable nginx
▼ 自動起動が設定されているか確認する
systemctl is-enabled [サービス名]
（例：nginxの状態を確認）
systemctl is-enabled nginx
実行結果として、「enabled（有効になってるよ！）」または「disabled（無効だよ！）」って、ちゃんと教えてくれます。
サービスの手動起動・停止・再起動 (start / stop / restart)
enable / disable は、あくまで「次回の起動時」の設定でしたよね。
でも、「今すぐ！」サービスを操作したい時だって、いっぱいあります！
そんな時は、「start」「stop」「restart」を使います。
▼ サービスを今すぐ起動する
sudo systemctl start [サービス名]
▼ サービスを今すぐ停止する
sudo systemctl stop [サービス名]
▼ サービスを今すぐ再起動する
sudo systemctl restart [サービス名]
この「restart」は、nginxとかの設定ファイル（nginx.confとか）を変更した後に、設定を反映させるために実行する、っていうケースで本当によく使いますよ！
サービスの現在の状態を確認する (status)
サービスが今、ちゃんと正しく動いているのか？
最後にいつ起動したのか？
もしかして、エラーとか発生してない…？
そんな時に不可欠なのが、この「status」サブコマンドです！
systemctl status [サービス名]
（例：nginxの状態を確認）
systemctl status nginx
このコマンドは、もうビックリするくらい、たくさんの情報を私たちに教えてくれます。
- Loaded: サービス定義ファイル（.service ファイル）が、ちゃんと読み込まれているか。
- Active: サービスが現在、動作中かどうか。（これが一番大事！）
- active (running): 正常に動作中です！やったね！
- inactive (dead): 停止しています。
- active (exited): 処理（一回きりの処理）を実行して、正常に終了しました。
- failed: （ヤバい！）起動に失敗したか、異常終了しました。
- Enabled / Disabled: 自動起動が設定されているか。
- ログ: 直近のログ（エラーメッセージとか）もここに表示されます。
サーバーで何かトラブルがあった時、まず最初にやるべきことは、関連するサービスの systemctl status を確認すること！
これ、もうサーバー管理者の鉄則ですよ！
【重要】linux サービス一覧の確認方法
「で、そもそも、このLinuxシステム上でどんなサービスが動いてるの？」
「どのサービスが自動起動する設定になっちゃってるの？」
これを知ることは、管理の基本中の基本ですよね。
▼ 現在メモリ上でアクティブな（起動中の）全ユニット一覧
systemctl list-units
でも、これだとサービス以外のものもいっぱい表示されて、ちょっと見づらいかも…。
そんな時は、サービス（.service）だけに絞り込むことができます。
systemctl list-units --type=service
▼ システムにインストールされている全サービスの「自動起動設定」一覧
こっちの方が、「linux サービス一覧」の確認としては、もっと実用的かもしれません！
systemctl list-unit-files --type=service
このコマンドは、インストールされてる全てのサービスが、今「自動起動が有効（enabled）」なのか「無効（disabled）」なのか、それとも「設定不可（static）」なのかを、ぜーんぶ一覧表示してくれます！
| STATE | 説明 |
|---|---|
| enabled | 自動起動が有効になっています。OS起動時に自動で起動します。 |
| disabled | 自動起動が無効になっています。手動で start するか、他のサービスから要求されない限り起動しません。 |
| static | 自動起動の有効/無効を設定できません。通常、他のサービスから依存関係として呼び出される（WantedBy= がない）サービスです。 |
| masked | サービスが「マスク」されています。enable も start もできない、最も強い無効化状態です。誤って起動するのを防ぎたい場合に使います。 |
systemctl list-unit-files –type=service | grep enabled みたいに grep と組み合わせれば、自動起動が有効なサービスだけを抜き出して見ることもできちゃいますよ。
【systemd編】OS起動時に任意のコマンドやスクリプトを実行する（linux 起動時 コマンド実行）
多くの人が「linux 起動時 コマンド実行」って検索する時、nginx みたいな既存のサービスのことじゃなくて、「自分で作ったシェルスクリプト」をOS起動時に実行したい！って考えているケースが、すっごく多いんですよね。
伝統的な rc.local は非推奨
昔のLinux（SysVinitっていう古い仕組み）では、/etc/rc.localっていうファイルに、実行したいコマンドをただ書いておくだけで、起動時の最後に自動で実行してくれたんです。
すっごくお手軽でしたよね。
でも…、systemdが主流になった現代では、この方法はもう非推奨なんです😥
なんでかって言うと、systemdはサービスの起動を並列でいっぱい実行して、OSの起動を速くしよう！って頑張ってるのに、rc.local に重たーい処理が書いてあると、その処理が終わるまで、システム全体の起動が待たされちゃう（ブロックされちゃう）可能性があるからなんです。
推奨：自作の .service ファイルを作成する
じゃあどうすればいいの！？っていうと、答えは「systemdの流儀に従う」ことです。
たとえ自分で作ったスクリプトであっても、それを実行するための「.service」ファイル（ユニットファイル）を、ちゃんと自分で作ってあげる。
これが、一番クリーンで、今風の、推奨される方法なんです！
これ、ちょっと面倒に聞こえるかもしれませんが、すっごいメリットがあるんですよ！
自作のスクリプトを、nginxとかと同じ、ちゃんとした「サービス」として扱えるようになるので、起動の順番（依存関係）を制御したり、異常終了したら自動で再起動させたり…っていう、systemdの強力な機能の恩恵をぜんぶ受けられるようになるんですから！
ステップ1：実行するシェルスクリプトの作成
まずは、起動時に実行させたいスクリプトを、いつも通り作ります。
（例：/usr/local/bin/my_startup_script.sh）
#!/bin/bash
起動時に実行したいスクリプト
作成したら、絶対に忘れちゃいけないのが「実行権限」の付与です！
これ、本当によく忘れるんですよね…（私もやりました😅）
sudo chmod +x /usr/local/bin/my_startup_script.sh
ステップ2： .service ファイルの作成
次に、このスクリプトを呼び出すための「お作法」である、.service ファイルを作ります。
作成する場所は、/etc/systemd/system/ の中が一般的です。
（例：/etc/systemd/system/my-startup.service）
[Unit]
Description=My Startup Script Service
このサービスが起動するタイミングを定義
(例：ネットワークが有効になった後に起動)
After=network.target
[Service]
Type=simple: メインプロセスが起動したら「起動完了」とみなす
Type=oneshot: 一回きりの処理（スクリプト実行など）に使う
Type=oneshot
RemainAfterExit=yes
実行するスクリプトのフルパス
ExecStart=/usr/local/bin/my_startup_script.sh
実行するユーザーやグループ（任意）
User=myuser
Group=mygroup
ちょっと難しそうに見えますが、大丈夫！
[Unit] セクション: サービスの説明（Description）や、起動の順番（After：〜の後に起動してね）を定義します。
[Service] セクション: サービスの振る舞い（Type=oneshot：一回実行したら終わるタイプだよ）や、実行するコマンド（ExecStart）を定義します。
[Install] セクション: systemctl enable した時に、どの起動モード（WantedBy：CUIの標準モード）に関連付けるかを定義します。
ステップ3： systemd に認識させ、有効化する
新しい .service ファイルを作ったり、変更したりしたら、systemdに「ねえねえ、ファイル変えたから、読み込み直して！」って教えてあげる必要があります。
sudo systemctl daemon-reload
そしたら、いよいよ私たちが作った新しいサービスを、自動起動（enable）しちゃいましょう！
sudo systemctl enable my-startup.service
たったこれだけです！
これで、次回のOS起動時から、自動で /usr/local/bin/my_startup_script.sh が実行されるようになりました！🎉✨
「今すぐ」実行を試してみたい場合は、start コマンドを使えばOKです。
sudo systemctl start my-startup.service
実行した後、ちゃんと動いたかどうか、status や、さっきスクリプトに仕込んだログファイル（/var/log/my_startup.log）を確認してみましょうね！
systemctl status my-startup.service
【cron編】指定日時の定期実行（linux 定期実行）
systemdが「状態の維持」を得意とするチャンピオンだったのに対して、「cron」は「時間ベースの実行」を得意とする、もう一人のチャンピオンです。
cronの設定は、「crontab（クロンタブ）」っていう、専用の設定ファイルに書き込んでいきます。
crontab（クロンタブ）の基本的な書き方
crontabは、6つの「魔法のフィールド」で構成されています。
呪文みたいですけど、すっごくカンタンですよ！
分 時 日 月 曜日 コマンド
- 分 (minute): 0〜59
- 時 (hour): 0〜23
- 日 (day of month): 1〜31
- 月 (month): 1〜12 (または jan, feb みたいな省略形もOK)
- 曜日 (day of week): 0〜7 (0と7はどっちも日曜日です。または sun, mon もOK)
- コマンド: 実行したいコマンド（絶対パスで書くのが超重要！）
アスタリスク（*）は、「ぜんぶ！（毎分、毎時）」っていう意味のワイルドカードです。
crontab の編集・確認・削除コマンド
cronの設定は、ぜんぶ「crontab」コマンドを使って行います。
（設定ファイルを直接編集するんじゃないんですね！）
▼ cron設定を編集する（最重要）
crontab -e
このコマンドを実行すると、デフォルトのエディタ（vi とか nano とか）が起動して、設定ファイルを編集できる状態になります。
▼ 現在の cron設定一覧を表示する
crontab -l
▼ 現在の cron設定をすべて削除する（注意！）
crontab -r
この -r は本当に気をつけてください！ なんの確認もなく、一瞬で全部消えちゃいますからね！😭
基本的には、「-e」で編集して、「-l」で確認する、この2つをメインで使います。
crontab の具体的な書き方（設定例）
crontab -e で開いたファイルに、こんなふうに呪文を書いていきます。
（例1）毎日深夜 2時0分にバックアップスクリプトを実行
0 2 * * * /usr/local/bin/backup.sh
（例2）毎週日曜日 の AM 4時30分にシステム再起動
30 4 * * 0 /sbin/reboot
（0 または 7 または sun が日曜日です）
（例3）毎時 0分（1時0分, 2時0分, ...）にコマンド実行
0 * * * * /path/to/command
（例4）5分ごとにスクリプトを実行
*/5 * * * * /path/to/script.sh
（*/n は「nごと」っていう意味です。便利！）
（例5）平日の 9時～18時の間、30分ごと（毎時0分と30分）に実行
0,30 9-18 * * 1-5 /path/to/command
（-（ハイフン）は範囲、,（カンマ）は複数指定、1-5 は月〜金です）
書式 意味 例 すべて（毎分、毎時など） * * * * （毎分） n指定した数値 10 * * * * （毎時10分） n,mn と m 0,30 * * * （毎時0分と30分） n-mn から m まで 0 9-17 * * （9時～17時の毎時0分） /nn ごと /10 * * * * （10分ごと）
ユーザー cron と システム cron
crontab -e で設定したのは、そのコマンドを実行した「ユーザー」個人のcron設定（/var/spool/cron/ に保存されます）で、そのユーザーの権限で実行されます。
これとは別に、「システム全体」で管理されるcron設定もあるんです。
- システムcron ( /etc/crontab ): システム全体の設定ファイルです。これ、ユーザーcronと書式がちょっとだけ違って、「実行ユーザー」を指定するフィールドが間に追加されるんです！
- （例：0 2 * * * <b>root</b> /usr/local/bin/system_backup.sh）
- cron.d ( /etc/cron.d/ ): アプリケーションが独自にcron設定を追加したい時に使うディレクトリです。ここに置かれたファイルは /etc/crontab と同じように扱われます。
- anacron ( /etc/cron.hourly|daily|weekly|monthly ): もっとお手軽な方法もあります！これらのディレクトリに実行権限を付けたスクリプトを「置くだけ」で、それぞれ「毎時」「毎日」「毎週」「毎月」実行してくれます。
- しかもこれ、anacronっていう賢い仕組みで管理されることが多くて、もし指定時間にPCの電源がオフになってても、次回起動した時に「あ、実行し忘れてた！」って気づいて実行してくれるんですよ！すごくないですか？
【重要】cron での「linux 起動時 コマンド実行」 (@reboot)
cronには、あの「分・時・日・月・曜日」っていう時間指定の代わりに使える、すっごく便利な「特殊な文字列」が用意されています。
その中で、私たちが「linux 起動時 コマンド実行」したい時に、もう最高に便利なのが「@reboot」です！
@reboot /path/to/your/script.sh
crontab -e で、たったこれだけを書いておくだけで、OSが起動したタイミング（正確には crond デーモンが起動したタイミング）で、指定したコマンドを一回だけ実行してくれるんです！
さっきのsystemdみたいに、わざわざ .service ファイルを作成するほどでもない、本当に簡単な起動時実行であれば、この <b>@reboot</b> を使うのが、もう圧倒的に手軽な方法です！
ただし！
systemdみたいに「ネットワークが有効になってから実行してね！」みたいな、複雑な依存関係の管理はぜんぜんできません。
なので、実行するタイミングがシビアな処理には、やっぱり向いてないんですね。
cron ジョブの管理とトラブルシューティング（linux ジョブ 確認）
cron を設定したのはいいんだけど、「あれ…？なぜか動かない！」「実行されたのかどうかも、わかんない！」
これ、cron運用あるあるの、最たるものですよね…😥
「linux ジョブ 確認」は、cronを使いこなすための、もう一つの肝（キモ）なんです！
cron ジョブが実行されたか確認する方法
cronがジョブを実行すると、通常はシステムの「ログ」に、ちゃんとその足跡（記録）が残されます。
▼ CentOS / RHEL 系のログ確認
sudo journalctl -u crond.service
または
sudo grep CRON /var/log/cron
▼ Debian / Ubuntu 系のログ確認
sudo journalctl -u cron.service
または
sudo grep CRON /var/log/syslog
journalctl を使う場合は、-f オプションでログをリアルタイムに監視したり、-S "10 minutes ago" で「直近10分間」のログだけを表示することもできて、すっごく便利ですよ！
ログには、いつ、どのユーザーが、どのコマンド（CMD）を実行しようとしたかが、ちゃーんと記録されています。
cron がうまく動かない時のチェックリスト
「手動でコマンドを打つと成功するのに、cronで実行すると、なぜか失敗する…」
もしそんな状態なら、犯人は「実行環境の違い」です、間違いありません！
私たちがターミナルで実行する時と、cronが実行する時とでは、世界（環境変数とか）がぜんぜん違うんです…。
⚠️cron トラブルシューティングの「4箇条」⚠️
- コマンドやスクリプトは「絶対パス」で指定しているか？
cron実行時は PATH 環境変数が最小限しか設定されてません！
（NG例）
* * * * * my_script.sh
（OK例）* * * * * /home/user/my_script.sh
backup みたいなコマンドでも、which backup でフルパス（例：/usr/bin/backup）を調べて、絶対パスで指定するのが鉄則です！ - スクリプトに実行権限（+x）は付与されているか？
chmod +x /path/to/script.sh を忘れちゃってて、動かないケース、すっごく多いです（私です）。
- スクリプト内の「環境変数」は解決できているか？
スクリプトが内部で ~/.bashrc とかで設定した環境変数（JAVA_HOME とか）に依存してると、cronからは実行できません。
スクリプトの冒頭で source /home/user/.bashrc するか、必要な変数をスクリプト内で直接定義してくださいね。
- crond デーモンは起動しているか？
めったにないですけど、念のため…。
systemctl status crond (または cron) で状態を確認してみましょう。
5. 標準出力・標準エラー出力をログにリダイレクトする（超重要）
cronは、実行結果（エラーとか）を「メール」でユーザーに送信しようとします。
でも、メールサーバーなんて設定してないよ！っていう場合、エラーが出ても、それに気づくことすらできないんです…。
だから、トラブルシューティング中は、以下のように設定して、標準出力(1)と標準エラー出力(2)を、ぜんぶログファイルに書き出す（>>）ようにしちゃいましょう！
*/5 * * * * /path/to/script.sh >> /var/log/my_cron.log 2>&1
「2>&1」っていうのは、「標準エラー出力（2番）も、標準出力（1番）と同じ場所（＝この場合はログファイル）に送ってね！」っていう、魔法のおまじないです。
このログファイル（/var/log/my_cron.log）の中身を見れば、あなたのスクリプトがどんなエラーを吐いて止まっちゃってるのか、一目瞭然になりますよ！💪✨
関連知識：Linuxの起動プロセスと管理（ランレベル・reboot）
systemdは、サービスの自動起動だけじゃなくて、OSの起動プロセス「ぜんぶ」を管理してるんだよ、ってお話しましたよね。
この章では、戦略的意図として求められた「ランレベル」「reboot」「レスキューモード」について、systemdの観点から、しっかり解説しちゃいますね！
systemdにおける「ターゲット (target)」とは？（旧来のランレベル）
systemdが普及する前の古いLinux（SysVinit）では、「linux ランレベル」っていう概念で、システムの動作モードを 0〜6 の数字で定義していました。
- ランレベル0: シャットダウン
- ランレベル1: シングルユーザーモード（メンテナンス用）
- ランレベル3: CUI（マルチユーザー、ネットワークあり）
- ランレベル5: GUI（マルチユーザー、ネットワークあり、グラフィカル）
- ランレベル6: 再起動
でも、systemdでは、この「ランレベル」の代わりに「ターゲット（.target ユニット）」っていう、もっとカッコイイ概念が使われるようになったんです。
ターゲットっていうのは、特定の状態（例えば「GUIが使える状態」）にするために必要な、複数のサービスユニットをひとまとめにグループ化したもの、ってイメージです。
ちゃんと、昔のランレベルと対応するターゲットが用意されていますよ。
旧ランレベル systemd ターゲット 説明 0 poweroff.targetシステムのシャットダウン 1 rescue.targetlinux レスキューモード（最小限のサービス） 2, 3, 4 multi-user.targetCUIでのマルチユーザーモード（サーバーの標準） 5 graphical.targetGUIでのマルチユーザーモード（デスクトップの標準） 6 reboot.targetシステムの再起動（linux reboot）
現在のターゲット（ランレベル）の確認と変更
▼ デフォルトの起動ターゲット（OS起動時に到達するターゲット）を確認
systemctl get-default
（実行結果例：graphical.target）
▼ デフォルトの起動ターゲットを変更
（例：GUI起動（デスクトップ）をCUI起動（サーバー）に変更する）
sudo systemctl set-default multi-user.target
▼ 現在のターゲット（ランレベル）を一時的に変更
「isolate」コマンドを使うと、OSを再起動しなくても、現在のターゲットを切り替えることができます。
（例：GUIモードからCUIモードに（一時的に）切り替える）
sudo systemctl isolate multi-user.target
Linux の再起動とシャットダウン（linux reboot）
システムの再起動やシャットダウンも、もちろん systemd（systemctl）が管理しています。
「reboot」や「poweroff」みたいな、昔ながらの伝統的なコマンドも使えますけど、実は、最近のシステムだと、それらのコマンドは内部的に systemctl の別名（エイリアス）になってることが多いんですよ。
▼ 再起動
sudo systemctl reboot
または
sudo reboot
▼ シャットダウン（電源OFF）
sudo systemctl poweroff
または
sudo poweroff
「shutdown」コマンドも、もちろん引き続き利用可能です！
systemd環境では、shutdown コマンドも、systemdに「シャットダウンお願い！」ってリクエストを送る、賢いラッパーとして機能してくれます。
▼ 10分後に再起動（メッセージ付き）
sudo shutdown -r +10 "10分後にメンテナンスのため再起動します。作業を保存してください。"
▼ スケジュールされたシャットダウンをキャンセル
sudo shutdown -c
linux レスキューモード とは？
「rescue.target」（旧ランレベル1）は、システムが正常に起動しなくなっちゃった時とかに使う、緊急用のメンテナンスモードです。
rescue.target に移行すると、ネットワークやGUIみたいな主要なサービスは一切起動しないで、本当に最小限のシステム（ルートファイルシステムをマウントした状態）だけが起動します。
▼ 正常起動中にレスキューモードへ移行する
sudo systemctl isolate rescue.target
rootのパスワードを求められた後、シングルユーザーのCUIシェルに入ることができます。
▼ 起動しないシステムでレスキューモードに入る
システムが multi-user.target に到達できなくて、起動に失敗しちゃう…。
そんな時は、起動時のブートローダー（GRUB）の画面で、カーネルのパラメータに「systemd.unit=rescue.target」（または、昔ながらに数字の「1」だけでもOK）って追記して起動することで、強制的にレスキューモードに入ることができます。
このモードで、設定ファイルを修正したり、ファイルシステムをチェック（fsck）したり、systemdの .service ファイルのミスを直したり…っていう、システムの復旧作業を行うんですね。
【実践】ユースケース別・自動実行設定の選び方
ここまでの知識をぜーんぶ使って、よくあるシナリオで、あなたが「systemd」と「cron」のどっちを使うべきか、具体的に判断してみましょう！
もうカンタンですよね？
ケース1：Webサーバー (Nginx) をOSと同時に起動し、常時稼働させたい
- 答え： systemd
- 理由： これは「状態の維持（常時稼働）」が目的の、典型的な「linux サービス」だからです！
- コマンド：
sudo systemctl enable nginx
ケース2：自作の常駐監視スクリプト（Python等）をOS起動時に実行したい
- 答え： systemd （推奨）
- 理由： 常駐プロセス（デーモン）として動かしたいなら、systemdで .service ファイルを作るのが最適解！異常終了時の自動再起動（Restart=on-failure）とかも設定できますしね！
- コマンド： 自作の .service ファイルを作成して、
sudo systemctl enable my-app.service
ケース3：毎日深夜3時にデータベースのバックアップスクリプトを実行したい
- 答え： cron
- 理由： 「毎日深夜3時」っていう、「時間ベース」の実行が目的だからです！
- コマンド：
crontab -e で 0 3 * * * /path/to/backup.sh を追記
ケース4：1時間ごとにサーバーのディスク使用量をログファイルに記録したい
- 答え： cron
- 理由： 「1時間ごと」っていう、これも「時間ベース」の定期実行だからです。
- コマンド：
crontab -e で 0 * * * * df -h >> /var/log/disk_usage.log を追記 （または、お手軽に /etc/cron.hourly/ にスクリプトを置く）
ケース5：OS起動時に、/tmp ディレクトリ配下の一時ファイルを掃除したい
- 答え： systemd または cron (@reboot)
- 理由： OS起動時に「一回だけ実行」する処理ですよね。
- 推奨： 実は、systemdには systemd-tmpfilesっていう一時ファイル管理専用の、もっと賢い仕組みがすでにあって、そっちが自動でやってくれることが多いです。
- 代替： もし独自のルールで掃除したいなら、簡単なスクリプトを
crontab -e で @reboot /path/to/cleanup.sh って書くのが、一番手軽ですね！
安定したサーバー運用なら高機能なVPSがおすすめ
ここまで、systemd や cron を使ったLinuxサーバーの管理方法について、詳しく解説してきました！
これらの設定を安定して動かし続けるには、当然ですけど、信頼性の高いサーバー環境が、絶対に必要不可T欠ですよね。
自宅のPCや、古いマシンをサーバー代わりにして学習するのも、もちろんすっごく良いことです！
でも、実際にWebサービスやボットを「24時間365日」動かし続けたい！って思うなら、やっぱり専門のサーバーをレンタルするのが、一番現実的なんです。
特に、systemd によるサービス管理や、cron による定期実行を、本気で学んで、実践する場として、「VPS（仮想専用サーバー）」は、もう最適の環境です！
VPSなら、月額たったの数百円～数千円程度で、あなた専用の「root権限付きLinuxサーバー環境」を、まるごと手に入れることができちゃいます。
- 24時間安定稼働: 自宅のPCみたいに、電源を気にする必要がありません！
- 固定グローバルIP: 外部から安定してアクセスできる、自分だけの住所が手に入ります。
- クリーンな環境: いつでもOSを再インストールできるので、systemd や cron の設定を、何度失敗しても大丈夫！ ゼロから何回でも試すことができます。
nginx の自動起動設定（systemctl enable nginx）を試したり、cron でバックアップジョブを（@reboot も含めて）組んでみたり…。
そういう「実践の場」として、VPSはあなたにとって最高の学習環境になってくれるはずですよ！
まとめ
今回は、Linuxサーバー管理の「要（かなめ）」である、「自動起動（systemd）」と「定期実行（cron）」について、その違いから具体的な設定方法、関連知識までを、網羅的に解説してきました！
この記事で解説した対処法を、もう一度おさらいしますね。
✅ OS起動時のサービス管理 (linux 自動起動):
- systemd を使います！
- サービスの有効化/無効化:
sudo systemctl enable/disable [サービス名] - サービスの起動/停止/状態確認:
sudo systemctl start/stop/status [サービス名]
✅ 指定日時のタスク実行 (linux 定期実行):
- cron を使います！
- 設定の編集:
crontab -e - 書式: 分 時 日 月 曜日 コマンド
✅ 自作スクリプトの起動時実行 (linux 起動時 コマンド実行):
- 推奨: systemdで自作の .service ファイルを作成する（依存関係や再起動を管理できるから）
- 簡易: cron の
@reboot を使う（手軽だけど、実行タイミングは制御しにくい）
✅ サービス一覧の確認 (linux サービス一覧):
systemctl list-unit-files --type=service で、自動起動設定の一覧がぜんぶ見られます！
✅ ジョブの確認 (linux ジョブ 確認):
- cronの実行ログ（
/var/log/cron や journalctl -u cron）を、まず確認！ - cronが動かない時は、「絶対パス指定」「環境変数」「実行権限」を、もう一度よーく疑ってみてください！
✅ 関連知識:
- 旧来の「linux ランレベル」は、systemdの「ターゲット（multi-user.target など）」に置き換わりました。
- 「linux reboot（再起動）」や「linux レスキューモード（rescue.target）」も、systemctl コマンドでスマートに管理されます。
systemd と cron は、どちらもLinuxサーバーを「自動化」して、私たち管理者の手間を、もう劇的に減らしてくれる、すっごく強力なツールです。
それぞれの役割と得意分野を正しく理解して、適切に使い分けることこそが、安定したサーバー運用の、最高の一歩になりますからね！💪✨
コメント