systemdでプログラムを自動起動！初心者でもわかる設定方法⚙️

はじめに (対象読者・この記事でわかること)

この記事は、「Linuxサーバーを起動した際に、特定のアプリケーションやスクリプトを自動的に実行したい」と考えている方、特にプログラミング初心者の方やサーバー管理に慣れていない方を対象としています。

この記事を読むことで、Linuxの標準的なサービス管理システムであるsystemdの基本的な仕組みを理解し、自身で作成したプログラムや、必要不可欠なサービスをサーバー起動時に自動実行させるための設定ファイル（ユニットファイル）を作成・適用できるようになります。また、よくある疑問点やトラブルシューティングのヒントも盛り込んでいるため、安心して設定に挑戦していただけるはずです。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。

• Linuxの基本的なコマンド操作: cd, ls, mkdir, vi (またはnano) などの基本的なコマンドが使えること。
• テキストエディタの基本操作: ファイルの作成、編集、保存ができること。

systemdとは？ – Linuxのサービス管理の要

systemdは、現代の多くのLinuxディストリビューションで標準採用されている、システムとサービスを管理するためのフレームワークです。従来のinitシステムに代わり、起動・停止・管理といったプロセスを効率的に行います。

systemdの最も重要な概念の一つに「ユニット」があります。ユニットとは、systemdが管理する対象の総称で、主に以下の種類があります。

• Service Unit (.service): プログラムやスクリプトなどのサービスを定義します。
• Target Unit (.target): 複数のユニットをグループ化し、特定の状態（例: GUIログイン画面、ネットワーク起動完了）を表します。
• Socket Unit (.socket): ネットワークソケットなどを定義します。
• Timer Unit (.timer): 特定のスケジュールでサービスを起動します。

今回、我々が注目するのはService Unitです。これを利用することで、任意のプログラムをバックグラウンドで実行させたり、指定したタイミングで起動・停止したりといった自動化が可能になります。

プログラムをsystemdで自動起動させる方法

ここからが本題です。systemdを使って、あなたのプログラムをサーバー起動時に自動実行させるための具体的な手順を解説します。

1. サービス化したいプログラムの準備

まず、自動起動させたいプログラム（ここでは例として、簡単なPythonスクリプトを想定します）を用意します。

例: my_app.py

Python

#!/usr/bin/env python3
import time
import sys

def main():
    print("My application started!")
    try:
        while True:
            print(f"[{time.ctime()}] My application is running...")
            time.sleep(10)
    except KeyboardInterrupt:
        print("My application stopping...")
        sys.exit(0)

if __name__ == "__main__":
    main()

このスクリプトは、起動すると「My application started!」と表示し、その後10秒ごとに「My application is running...」とログを出し続けます。Ctrl+Cで終了できる状態です。

このスクリプトを、サーバー上のどこか実行しやすい場所（例: /opt/my_app/my_app.py）に配置し、実行権限を付与しておきましょう。

Bash

sudo mkdir /opt/my_app
sudo cp my_app.py /opt/my_app/
sudo chmod +x /opt/my_app/my_app.py

2. systemdユニットファイルの作成

次に、このPythonスクリプトをsystemdのサービスとして管理するためのユニットファイルを作成します。ユニットファイルは、.serviceという拡張子を持ち、通常は/etc/systemd/system/ディレクトリに配置します。

ファイル名は、サービス名に合わせて命名します（例: my_app.service）。

Bash

sudo vi /etc/systemd/system/my_app.service

ファイルに以下の内容を記述します。

Ini

[Unit]
Description=My Custom Application
After=network.target # ネットワークが利用可能になってから起動したい場合

[Service]
Type=simple # プログラムがフォアグラウンドで実行されることを示す
ExecStart=/usr/bin/python3 /opt/my_app/my_app.py # 実行するコマンドを指定
Restart=on-failure # 失敗した場合に自動再起動させる
User=your_user # サービスを実行するユーザー (必要に応じて変更)
Group=your_group # サービスを実行するグループ (必要に応じて変更)

[Install]
WantedBy=multi-user.target # どのターゲットで起動するか (通常は multi-user.target)

各セクションとディレクティブの意味は以下の通りです。

• [Unit] セクション: サービス自体の情報や、他のサービスとの依存関係を定義します。
  • Description: サービスの説明文です。
  • After: このサービスが起動する前に、指定したユニット（ここではネットワーク）が起動していることを保証します。
• [Service] セクション: サービス自体の実行方法を定義します。
  • Type=simple: 最も基本的なタイプで、ExecStartで指定されたプロセスがフォアグラウンドで実行されることを意味します。
  • ExecStart: サービス起動時に実行されるコマンドのフルパスを指定します。python3のパスやスクリプトのパスは、ご自身の環境に合わせてください。
  • Restart=on-failure: プログラムが何らかの理由で終了した場合（クラッシュなど）、自動的に再起動します。他にもalways（常に再起動）、no（再起動しない）などがあります。
  • User/Group: サービスを実行する際のユーザーとグループを指定します。セキュリティのために、root権限が不要な場合は、特定の一般ユーザーを指定することを推奨します。
• [Install] セクション: サービスを有効化（自動起動設定）した際に、どのターゲットにリンクされるかを定義します。
  • WantedBy=multi-user.target: サーバーがテキストモードで起動した際に、このサービスも起動するように設定します。GUI環境の場合はgraphical.targetを指定することもあります。

注意: * UserやGroupを指定しない場合、デフォルトではroot権限で実行されます。セキュリティ上、必要最小限の権限で実行するように設定することが推奨されます。 * Pythonスクリプトに#!/usr/bin/env python3（シェバン）を記述していても、ExecStartでpython3コマンドを明示的に指定するのが確実です。

3. systemdへのユニットファイルの登録と有効化

ユニットファイルを作成したら、systemdにその存在を認識させ、自動起動するように設定します。

まず、systemdに新しいユニットファイルを読み込ませます。

Bash

sudo systemctl daemon-reload

次に、作成したサービスを有効化します。これにより、サーバー起動時に自動的に起動するようになります。

Bash

sudo systemctl enable my_app.service

4. サービスの起動と状態確認

設定が完了したら、サービスを起動してみましょう。

Bash

sudo systemctl start my_app.service

サービスの現在の状態を確認するには、以下のコマンドを使用します。

Bash

sudo systemctl status my_app.service

active (running)と表示されていれば、サービスは正常に起動しています。ログも確認できます。

● my_app.service - My Custom Application
     Loaded: loaded (/etc/systemd/system/my_app.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2024-07-26 10:00:00 JST; 5s ago
   Main PID: 12345 (python3)
      Tasks: 1 (limit: 4915)
     Memory: 5.0M
        CPU: 50ms
     CGroup: /system.slice/my_app.service
             └─12345 /usr/bin/python3 /opt/my_app/my_app.py

Jul 26 10:00:00 your-server-hostname systemd[1]: Started My Custom Application.
Jul 26 10:00:00 your-server-hostname python3[12345]: My application started!
Jul 26 10:00:00 your-server-hostname python3[12345]: [Tue Jul 26 10:00:00 2024] My application is running...

5. サービスの停止、再起動、無効化

サービスの停止、再起動、自動起動の無効化も簡単に行えます。

• 停止: bash sudo systemctl stop my_app.service
• 再起動: bash sudo systemctl restart my_app.service
• 自動起動の無効化: bash sudo systemctl disable my_app.service

ハマった点やエラー解決

• ExecStartのパスが間違っている:

  • 症状: systemctl statusでfailedと表示され、ExecStartに関連するエラーメッセージが出力される。
  • 解決策: 実行したいプログラムのフルパスが正しいか、which python3やls -lで確認してください。また、スクリプトに実行権限が付与されているか確認しましょう。

• パーミッションの問題:

  • 症状: プログラムは手動で実行できるが、systemdで起動するとエラーになる。特にUser/Groupを指定した場合に発生しやすい。
  • 解決策: サービスを実行するユーザー/グループが、プログラムファイルや、プログラムがアクセスするファイル/ディレクトリに対して読み書き権限を持っているか確認してください。/opt/my_appディレクトリやmy_app.pyファイルに、指定したユーザー/グループの権限を付与する必要があるかもしれません。

• 依存関係の問題:

  • 症状: After=network.targetを指定しているのに、ネットワークが利用できない状態で起動してしまう。
  • 解決策: systemctl statusやjournalctl -u my_app.serviceで詳細なログを確認し、依存関係が正しく設定されているか見直してください。必要であればRequiresディレクティブなども検討します。

• ログの確認:

  • 症状: サービスが起動しない、または予期せぬ動作をする。
  • 解決策: journalctl -u your_service_name.serviceコマンドで、そのサービスのシステムログを確認するのが最も重要です。エラーメッセージから原因を特定できます。

まとめ

本記事では、Linuxのsystemdを使用して、作成したプログラムやスクリプトをサーバー起動時に自動起動させるためのユニットファイルの作成方法と、その管理方法について解説しました。

• systemdの基本と、サービス管理に用いるService Unitの役割を理解しました。
• ユニットファイルの構成要素（[Unit], [Service], [Install]）と、各ディレクティブの意味を学びました。
• 実際にPythonスクリプトを例に、ユニットファイルの作成、登録、有効化、起動、状態確認といった一連の流れを習得しました。
• よくあるエラーとその解決策についても触れました。

この記事を通して、皆さんのLinuxサーバー上で、必要なサービスを確実に、そして自動的に実行できるようになり、サーバー運用の効率化や信頼性向上に繋がるでしょう。 今後は、Timer Unitを利用した定期実行や、より複雑な依存関係を持つサービスの管理など、systemdのさらに高度な機能についても探求していくと、さらにサーバー管理の幅が広がるはずです。

参考資料

• systemd.service(5) — Linux manual page
• systemd - ArchWiki (日本語訳もあり)
• Linux Systemd Tutorial and How-To (英語)