Zenn
👻

Goで秒速デーモン化！systemctlでサービス管理する超カンタン入門ハンズオン

に公開
Go
daemon
systemctl
tech

はじめに

もしあなたがLinuxサーバでアプリケーションを動かしていたり、運用をお手伝いしているなら、systemctl start ...やsystemctl stop ...といったコマンドを目にしたことがあるかもしれません。例えばWebサーバやデータベース、ログ収集ツールなど、あらゆるサービスがこのsystemctlで管理されています。でも、「これを打つと裏で何がどう動いてるの？」と疑問に思ったことはないでしょうか。

「裏側がわからないまま使っていると不安」――この感覚は非常に自然なものです。人間、理解できないものは怖いですし、万一トラブルが起きたとき、何をどうすればいいのか分からず右往左往してしまいます。

でも逆に、「こんな風にdaemon（常駐プロセス）が動いており、systemctlはこのファイルを参照してサービスを操作しているんだ」と仕組みをイメージできるようになれば、サービス運用はぐっと身近なものになります。理解することで、原因不明のエラーに直面した際にも、どこを確認すればよいのか、何を修正すればよいのかがつかみやすくなるのです。

本記事では、そんな「裏側が見えない不安」を解消するために、Go言語で書いた小さなプログラムをsystemctlで管理するサービスとして登録してみるという、手を動かすハンズオンを行います。難しい設定や膨大なコードを書く必要はありません。ごくシンプルな「バックグラウンドで動くアプリ」を自分で仕上げ、systemctl start exampledaemonapp.serviceで起動できるようになるまでの流れを体験します。

この記事を読み終える頃には、

  • daemonがどんなものかイメージできる
  • systemctlとサービス管理の基本的な関係を理解できる
  • 自作のGoプログラムをサービスとして動かし、起動・停止できるようになる

といった成果を得ることができるでしょう。「なんとなく怖かった裏側」にぐっと近づく準備、始めていきましょう。

「daemon」と「サービス管理」ってなに？

daemon（デーモン）という言葉は、UNIX文化において「バックグラウンドで静かに動作し続けるプログラム」を意味します。ユーザーが直接コンソールで操作したり、フォアグラウンドで画面を占有することなく、見えないところで常時稼働し、必要な処理を継続する存在です。Webサーバやメールサーバ、ログ収集エージェント、バックアップツールなど、多くの基盤サービスはdaemonとして動いており、Linuxサーバの安定稼働を影で支えています。

一方で、systemctlはsystemdと呼ばれるサービス管理システムへのインターフェイスです。systemdはLinux上でのプロセスとサービス管理を体系立てた仕組みで、systemctl startやsystemctl stopは「特定のサービスを起動・停止する命令」をsystemdに伝えているに過ぎません。
このときsystemctlが使う設定ファイルが「ユニットファイル（.serviceファイル）」です。
例えば、/etc/systemd/system/myapp.serviceというファイルに「どうやってそのdaemonを起動するか」「落ちたら再起動するか」「どのユーザー権限で動かすか」といった情報が書かれています。

整理すると、

  • daemon：裏側で動く実行プログラム自体
  • サービス (systemdのサービスユニット)：daemonを含めた、起動手順・実行環境・再起動ポリシーなどをまとめた管理単位

つまり、daemonは「役者」であり、サービス（ユニットファイル）は「台本と指示書」です。そしてsystemctlが「指示する監督役」となって、台本（ユニットファイル）を元に役者（daemon）に「出番だよ！」と声をかけたり、休憩させたりしているわけです。

こうした役割分担を理解しておくと、systemctl start <app name>が内部で何をしているのかが少しずつ想像できるようになります。これが、ただのコマンド入力から一歩踏み込んで不安を解消し、自信を持ってサービス運用を行うための第一歩となるのです。

この後は、実際にGo言語でミニマルなdaemonプログラムを用意し、サービスユニットを作成して、systemctlで制御できるようにしてみましょう。理解は手を動かすことでより深まります。さあ、コードを書いて、仕組みを体験していきましょう！

準備：Goプログラムで常駐サービスの土台を作る

ここからは、実際にGo言語で簡単な「常駐動作するプログラム」を作成し、その後systemctlで管理できるようにしていきます。
前提として、Goがインストール済みであることを想定しています（go versionコマンドでバージョンが表示されればOKです）。

1. 作業ディレクトリの用意

exampledaemonappという名前のディレクトリを作成して、そこに移動します。

mkdir exampledaemonapp
cd exampledaemonapp

2. Go コードを書く

以下は、5秒おきにメッセージを出力するだけの単純なプログラムです。

package main

import (
    "fmt"
    "time"
)

func main() {
    for {
        fmt.Println("exampledaemonapp is running...")
        time.Sleep(5 * time.Second)
    }
}

このプログラムは起動すると、無限ループでメッセージを出力し続けます。コンソールで実行すれば、Ctrl+Cで止めない限り動き続ける「常駐的」な挙動を確認できます。

3. Go プログラムのビルド

以下のコマンドで実行ファイルをビルドします。

go build -o exampledaemonapp
go mod について

必要に応じて go mod ファイルを作成する必要があります。今回は下記のコマンドを利用します。

go mod init example.com/exampledaemonapp
go mod tidy

exampledaemonappという実行ファイルが生成されます。

試しに./exampledaemonappを実行すれば、「exampledaemonapp is running...」というメッセージが5秒おきに表示され続けます。
Ctrl+Cで一度止めておきましょう。

4. ファイルの配置と権限設定

systemdでサービスとして管理するには、バイナリをシステム全体で参照しやすい場所（例：/usr/local/bin/）へ配置します。

sudo cp exampledaemonapp /usr/local/bin/exampledaemonapp

続いて、rootオーナーかつ適切なパーミッションを設定します（755で「オーナーが読み書き実行、その他ユーザーが読み実行可能」）。

sudo chown root:root /usr/local/bin/exampledaemonapp
sudo chmod 755 /usr/local/bin/exampledaemonapp

これで、/usr/local/bin/exampledaemonappとしてシステム全体から実行可能な状態になりました。

serviceファイルの作成と配置

systemdは.serviceファイルを通じてサービスを管理します。このファイルに「どのプログラムをどのユーザーで、どのように起動するか」を記述し、/etc/systemd/system/に置くことでsystemctlコマンドで管理できるようになります。

1. サービスユニットファイルの基本構造

.serviceファイルには基本的に[Unit]、[Service]、[Install]セクションがあります。

  • [Unit]：サービスの説明や依存する機能
  • [Service]：起動コマンド、実行ユーザー、再起動ポリシーなど
  • [Install]：systemctl enableでの自動起動設定

2. exampledaemonapp.serviceファイルの作成

exampledaemonapp.service というファイル名で、以下の内容を用意します。

[Unit]
Description=Example Daemon App in Go
After=network.target

[Service]
ExecStart=/usr/local/bin/exampledaemonapp
Restart=always
Group=nogroup

[Install]
WantedBy=multi-user.target

解説：

  • Description：サービスの説明。systemctl status exampledaemonapp.serviceで表示されます。
  • After=network.target：ネットワーク起動後に起動（例示的な指定で必須ではありません）。
  • ExecStart：サービス起動時に実行するコマンドを指定します。ここでは/usr/local/bin/exampledaemonappを指定。
  • Restart=always：プロセスが落ちた際に自動再起動するように設定。
  • Group：exampledaemonappをどのユーザー権限で実行するかを指定しています（必要に応じて変更可能）。
  • WantedBy=multi-user.target：systemctl enableでOS起動時にこのサービスが有効になるターゲットを指定します。

3. ファイルの配置

作成したexampledaemonapp.serviceを/etc/systemd/system/に配置します。

sudo cp exampledaemonapp.service /etc/systemd/system/exampledaemonapp.service

4. 設定の再読み込み

新しいサービスユニットファイルを systemd に認識させるため、daemon-reloadを実行します。

sudo systemctl daemon-reload

5. サービスの起動と確認

systemctlを使ってサービスを起動します。

sudo systemctl start exampledaemonapp.service
sudo systemctl status exampledaemonapp.service

ステータスがactive (running)と表示されていれば成功です。
journalctl -u exampledaemonapp.serviceでログを表示すると、「exampledaemonapp is running...」が定期的に出力されていることが確認できます。

6. 自動起動の有効化（任意）

サーバーが再起動した際もこのサービスを自動的に起動したい場合は、以下を実行します。

sudo systemctl enable exampledaemonapp.service

systemctl による管理ハンズオン

Goで作ったプログラムを .service ファイルに登録した後は、systemctlコマンドを使ったサービス管理をハンズオン形式で体験してみましょう。

1. サービス起動とステータス確認

サービスの起動

sudo systemctl start exampledaemonapp.service
  • systemctl start <service> で、exampledaemonapp.service の記述に従って実行ファイルがバックグラウンドで起動します。

ステータス確認

sudo systemctl status exampledaemonapp.service
  • Active: active (running) と表示されれば正常に起動しています。
  • journalctl -u exampledaemonapp.service --no-pager でサービスのログを確認できます。

停止と再起動

サービスの停止

sudo systemctl stop exampledaemonapp.service
  • バックグラウンドで動いていた exampledaemonapp が停止します。
  • stop 後に systemctl status を見ると inactive (dead) となっているはずです。

サービスの再起動

sudo systemctl restart exampledaemonapp.service
  • 一度停止し、再起動するのが restart です。ソフトウェア更新や設定変更後にサービスを再起動する際によく使われます。

2. 自動起動（enable/disable）の設定

自動起動を有効化

sudo systemctl enable exampledaemonapp.service
  • OS再起動後、自動的に exampledaemonapp.service が起動するようになります。
  • 実際には /etc/systemd/system/multi-user.target.wants/ ディレクトリなどにシンボリックリンクが作成されます。

自動起動を無効化

sudo systemctl disable exampledaemonapp.service
  • 自動起動をやめたい場合はこちらを実行します。

3. ユニットファイルを更新した場合の手順

.service ファイルを修正した際は、必ず以下の手順を踏む必要があります。

  1. ユニットファイル（/etc/systemd/system/exampledaemonapp.service）を編集
  2. sudo systemctl daemon-reload でsystemdの設定を再読み込み
  3. sudo systemctl restart exampledaemonapp.service または start を実行

変更内容を有効にしないまま再起動しようとすると、古い設定がそのまま使われるので注意しましょう。

4. ログの監視と確認

systemdが収集するログ

journalctl -u exampledaemonapp.service -f
  • -f オプションを付けると、リアルタイムでログが追いかけ表示されます（類似コマンドとして tail -f ）。
  • ログメッセージを見ながら動作状況をチェックし、必要なデバッグ情報を得ることができます。

OS全体のログを見る

journalctl -xe
  • サービスに限らず、OS全体で発生した重要ログ・エラー情報をタイムリーに確認可能。
  • 何か予期しないトラブルが起きた際は、まずここをチェックすると手掛かりを得られる場合が多いです。

トラブルシューティング：詰まったときの対処法

サービスの起動に失敗したり、systemctl statusでfailedと出るケースでは、以下の手順で原因を探ってみましょう。

1. まずはユニットの失敗状況を確認

systemctl list-units --failed
  • 現在「失敗（failed）」状態となっているユニットが一覧表示されます。
  • exampledaemonapp.service が含まれているか確認し、該当ユニットが1つでも失敗していると、systemctl status全体でState: degradedが表示されることがあります。

2. 詳細ステータスとログをチェック

systemctl status exampledaemonapp.service
journalctl -u exampledaemonapp.service --no-pager
  • statusコマンドは簡易ログやエラーコードを表示します。
  • journalctl はより詳細なログを確認できるため、エラーの内容を深掘りできます。

ログに現れがちなエラーメッセージ例：

  • ExecStart=/path/to/binary: No such file or directory
    • 実行ファイルのパスが間違っている、またはバイナリを配置し忘れ。
  • Failed at step EXEC spawning /usr/local/bin/exampledaemonapp: Permission denied
    • 実行権限が設定されていない (chmod 755 していない)。
  • status=216/GROUP
    • 指定した User / Group が存在しない、あるいはグループ名が合っていない（nobody vs nogroup など）。

3. ユニットファイルの誤記・パスミスを疑う

.serviceファイルでよくあるミスとしては：

  • ExecStartのパスが正しく指定されていない。
  • User・Group設定で、実在しないユーザー/グループ名を指定している。
  • 編集後に sudo systemctl daemon-reload をし忘れている。

4. 権限の問題をチェック

ls -l /usr/local/bin/exampledaemonapp
  • -rwxr-xr-x のように実行ビット（x）が付いていればOK。
  • 所有者・グループがroot:rootでも動作は可能です（ただしUserをnobodyにする場合は実行自体は問題ありませんが、バイナリの読み取り権限があるかなどを確認）。

5. 過度な再起動ループの回避

Restart=always や Restart=on-failure と設定している場合、何度も起動に失敗すると

Start request repeated too quickly.
Failed with result 'exit-code'.

のようなメッセージが出て、systemdが再起動をあきらめることがあります。ユニットファイルを見直し、必要に応じて RestartSec= などで再起動間隔を延ばすと対処しやすいです。

6. 本格的なデバッグ方法

どうしても原因がわからない場合は、さらなる情報を集める必要があります。

  • journalctl -b でシステム起動からの全ログをチェックし、関連エラーを検索。
  • プログラム本体にデバッグログを仕込む。
  • /var/log/syslog などOSの他のログを確認する。
  • SELinuxやAppArmorなどのセキュリティ機構が有効で、実行がブロックされている可能性を考慮する（Ubuntu標準ではAppArmorが有効）。

7. ケース別対処まとめ

  • パスが違う・実行権限がない：正しいディレクトリやパーミッションを再度設定する。
  • ユーザー・グループ指定の不備：設定値をnobody:nogroupなど実在する組み合わせにする。
  • サービス再起動時の設定ミス： .serviceファイルを編集したら daemon-reload を忘れない。
  • ログを必ずチェックする： エラー原因はログにヒントが出るケースがほとんど。

まとめ

  • systemctl管理では、start/stop/restart/enable/disable/status といった基本コマンドを使いこなすと便利。
  • トラブルシューティング時は、まず「失敗ユニットの特定→ログの確認」という流れが基本。パス設定やユーザー・グループ指定などにミスがないかを重点的にチェックする。
  • 設定変更→daemon-reload→再起動 が基本ワークフロー。

こうした手順を意識すれば、Go言語で書いた常駐アプリを安定してサービス運用できるようになります。またトラブルが起きてもログを確認しながら冷静に原因を特定できるため、systemctlやdaemon管理への不安がグッと軽減されるでしょう。

まとめ・次のステップ

まとめ

  • Goプログラムの常駐化

    ごくシンプルなGoプログラムを作成し、バックグラウンドで動かす動作を体験しました。5秒おきにメッセージを出すだけでも「終わらないプログラム」がどのように常駐するのかを実感できます。

  • systemdによるサービス管理の基本

    .service ファイルを /etc/systemd/system/ に配置し、systemctlコマンドで起動・停止・ステータス確認を行いました。systemctl daemon-reloadなどの基本的な手順も習得できたはずです。

  • トラブルシューティングの流れ

    「ユニットファイルのパス指定や権限のミス」「User/Group の不一致」「daemon-reloadのし忘れ」など、よくあるエラーの原因と対処法を学びました。何か起きたときはsystemctl statusやjournalctl -u <サービス名>でログを確認し、落ち着いて対処すればOKです。

今回のハンズオンを通じて、systemctlとdaemon（常駐プロセス）の裏側を少しだけ体感できたと思います。これまで「よくわからないからなんとなく怖い」と感じていた部分が、ひとつずつクリアになったのではないでしょうか。

次のステップ

1. 本格的な設定への発展

  • RestartSec=など細かいパラメータを使った自動再起動ポリシーの調整。
  • 環境変数の設定やEnvironmentFile=ディレクティブを使った運用を学ぶ。

2. 通知や制御の高度化

  • systemdのサービス通知 機構を使って、アプリ起動完了をsystemdに知らせる方法。
  • サービス依存関係（Requires=,Wants=など）を利用して、システム全体のユニット連携を管理。

3. ログ管理の強化

  • 外部のログ収集ツールやローテーション設定との連携。
  • syslogやrsyslogへのログ転送など、より大規模な運用環境に適用するノウハウを習得する。

4. ユーザー定義のユーザー/グループの活用

  • nobody:nogroupではなく、独自に「exampleapp」ユーザーを作成し、権限を最低限に絞ることで安全性を高める。
  • SELinuxやAppArmorなどのセキュリティ機構と組み合わせたよりセキュアな構成。

5. DockerやKubernetesなどのコンテナオーケストレーション

  • さらに応用編として、GoアプリをDockerイメージ化し、Kubernetes上で運用する技術へ発展させられます。

これらを学ぶことで、実際のプロダクション環境でも役立つ運用スキルが身に付くでしょう。今回のハンズオンで得た「常駐アプリとsystemctl管理への理解」は、あらゆるサーバサイド・インフラ構築の基礎になるはずです。

おわりに

ここまでお付き合いいただき、ありがとうございます。この記事では、Go言語で書いた小さなプログラムをsystemctlで管理する手順を通して、daemon（常駐プロセス）の正体とsystemd（systemctl）の仕組みをハンズオン形式で解説しました。

  • 漠然と不安だったdaemonの概念が、コードを動かすことでクリアになったのではないでしょうか。
  • 「systemctlって何をしているの？」という疑問が、自分で.serviceファイルを触ってみることで、「サービス管理ツールがアプリの起動・停止・監視をまとめてやってくれる仕組み」だということに腑に落ちたかと思います。
  • 万一トラブルが発生しても、systemctl statusやjournalctlなどのログをチェックすれば大抵の原因は掴めます。これは本番運用でも非常に大切なノウハウです。

本記事としては、「裏側の仕組みを噛み砕いて紹介し、実践を通じて不安を解消する」ことが狙いでした。本記事をきっかけに、さらに興味が湧いた方は他のサービス（WebサーバやDBなど）も同じ要領で管理してみると良いでしょう。実践を重ねるほど、systemctlによるサービス管理が「当たり前」に感じられるようになるはずです。

今後、より複雑なシステム運用やセキュリティ強化にも挑戦してみてください。Goで書いたプログラムを習熟しながらインフラの知識を深めていけば、実運用の場面で大いに役立つはずです。それが、あなたが新しいステージへ進むきっかけになることを願っています。

それでは、最後までありがとうございました。これからの開発や運用が、より安心でスムーズに進みますように！

Discussion