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

この記事は、CentOS 6以前の古いLinuxディストリビューションや、意図的にsystemdを導入していないMinimal環境など、systemctlコマンドやserviceコマンドが利用できないLinux環境に直面した方々を対象としています。特に、VPS（仮想専用サーバー）の初期設定や、レガシーなシステムを運用されている方にとって、サービスの起動・停止・状態確認といった基本的な操作ができず、途方に暮れた経験があるかもしれません。

この記事を読むことで、systemctlやserviceコマンドが存在しない環境で、どのようにサービスを管理すれば良いのか、その代替手段を理解できます。また、必要であればこれらのコマンドを後からインストールし、より現代的なサービス管理手法を導入するための具体的な手順も習得できます。これにより、Linuxサーバーの運用管理における手詰まり感を解消し、より効率的かつ安全にシステムを管理できるようになるでしょう。

前提知識

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

  • Linuxの基本的なコマンド操作（cd, ls, cat, viなど）
  • ファイルシステムの構造に関する基本的な理解
  • パッケージ管理システム（yumまたはapt）の基本的な使い方
  • root権限でのコマンド実行についての理解

systemctl/serviceコマンドがない状況と代替手段

なぜsystemctlやserviceコマンドがないのか？

systemctlコマンドはsystemdというinitシステムの一部であり、近年の多くのLinuxディストリビューション（CentOS 7以降、Ubuntu 15.04以降など）で標準的に採用されています。一方、serviceコマンドはSysVinit（System V init）という、より古いinitシステムで一般的に使用されていました。

したがって、systemctlやserviceコマンドが存在しない主な理由は以下の通りです。

  1. 古いLinuxディストリビューションの使用: CentOS 6以前やDebian 7以前など、systemdが導入されていない古いバージョンのOSを使用している場合。
  2. Minimalインストール: OSをインストールする際に、必要最低限のパッケージのみを選択した結果、systemdやSysVinit関連のパッケージがインストールされていない場合。
  3. 意図的な非導入: 特定の理由（例: 既存のスクリプトとの互換性、軽量化のため）で、systemdを意図的に無効化またはアンインストールしている場合。
  4. カスタムビルドのカーネル/OS: 標準的なディストリビューションとは異なる、カスタムビルドされたLinux環境を使用している場合。

これらの環境では、お馴染みのコマンドでサービスを管理できないため、代替手段を講じる必要があります。

代替手段1：直接initスクリプトを操作する (SysVinit環境)

serviceコマンドは、実際には/etc/init.d/ディレクトリにあるサービス管理用のシェルスクリプトを呼び出すラッパーです。systemctlが存在しない環境、特にSysVinitを使用している場合、これらのスクリプトを直接実行することで、サービスの起動・停止・再起動などを行うことができます。

基本的なコマンド例:

  • サービスの起動: bash sudo /etc/init.d/nginx start
  • サービスの停止: bash sudo /etc/init.d/nginx stop
  • サービスの再起動: bash sudo /etc/init.d/nginx restart
  • サービスのステータス確認: bash sudo /etc/init.d/nginx status （statusサブコマンドは、スクリプトによっては実装されていない場合があります。その場合は、ログファイルなどを確認する必要があります。）

注意点:

  • /etc/init.d/ディレクトリに、管理したいサービスのinitスクリプトが存在する必要があります。
  • スクリプトの引数（start, stop, restart, statusなど）は、各スクリプトの実装によって異なる場合があります。
  • runlevelコマンドやchkconfigコマンド（CentOS/RHEL系）を使用して、サービスの自動起動設定を確認・変更することも可能です。

代替手段2：systemdをインストール・有効化する

もし、systemctlコマンドが利用できない環境で、より現代的なサービス管理を行いたい場合は、systemdをインストールして有効化するのが最も推奨される方法です。これにより、systemctlコマンドが利用可能になり、サービスの管理が格段に容易になります。

CentOS/RHEL系 (yumを使用する場合):

  1. systemdパッケージのインストール: bash sudo yum install systemd （既にインストールされている場合もあります。）

  2. initシステムとしてのsystemdの有効化: この手順は、OSのバージョンや既存のinitシステムによって異なります。非常にデリケートな操作であり、誤るとシステムが起動しなくなる可能性があるため、必ずバックアップを取得し、十分な知識を持って実施してください。 一般的には、以下の手順が考えられますが、公式ドキュメントや信頼できる情報源で、ご自身の環境に合った正確な手順を確認することを強く推奨します。

    • GRUB/GRUB2の設定変更: ブートローダーの設定で、systemdをデフォルトのinitとして起動するように変更します。/etc/default/grubファイルを編集し、GRUB_CMDLINE_LINUXパラメータにinit=/bin/systemdなどを追加する、あるいはsystemdをデフォルトのtargetに設定するなどの作業が必要になる場合があります。
    • runlevelの変更 (古いシステムの場合): SysVinitからsystemdへの移行は、runlevelの概念も変更されるため、複雑になることがあります。

  3. 再起動: 設定変更後、システムを再起動します。 bash sudo reboot

  4. systemctlコマンドの確認: 再起動後、systemctlコマンドが利用できるか確認します。 bash systemctl --version systemctl status sshd

Debian/Ubuntu系 (aptを使用する場合):

  1. systemdパッケージのインストール: bash sudo apt update sudo apt install systemd

  2. initシステムとしてのsystemdの有効化: Debian/Ubuntu系では、systemdがデフォルトでインストールされていることが多いですが、もしインストールされていない場合や、別のinitシステム（upstartなど）から移行する場合は、以下の手順を参考にしてください。 こちらも、システムが起動しなくなるリスクがあるため、慎重に実施してください。

    • /etc/init/default-*.conf などの設定ファイルをsystemdのターゲット（multi-user.targetなど）に合わせる。
    • /etc/inittab ファイル（SysVinitの場合）の編集や、GRUBの設定変更が必要になる場合があります。

  3. 再起動: bash sudo reboot

  4. systemctlコマンドの確認: bash systemctl --version systemctl status ssh

重要な注意点: * OSのバージョンとディストリビューションごとのドキュメントを確認: systemdへの移行手順は、OSのバージョンやディストリビューション、さらにはインストールされているパッケージ構成によって大きく異なります。必ず、お使いのOSの公式ドキュメントや、信頼できる技術情報源を参照してください。 * リスクの理解: initシステムの変更は、システム全体の動作に影響を与えるため、非常にデリケートな操作です。万が一の事態に備え、必ず実行前にシステムのバックアップを取得してください。 * Minimal環境の場合: Minimalインストールでsystemd関連のパッケージが全くインストールされていない場合、依存関係の解決に手間取る可能性があります。

代替手段3：/proc/1/exeでinitプロセスの種類を確認する

現在、システムでどのinitプロセスが起動しているかを確認することで、どの代替手段が適切かを判断する手がかりになります。

Bash

ls -l /proc/1/exe

このコマンドの出力結果で、/sbin/initのシンボリックリンクが指している実行ファイルを確認します。

  • /sbin/init が /lib/systemd/systemd を指している場合 → systemdが使用されています (systemctlが利用可能であるはずです)。
  • /sbin/init が /sbin/sysvinit または /sbin/init.d などを指している場合 → SysVinitが使用されています (serviceコマンドや /etc/init.d/ スクリプトでの操作が主になります)。
  • 上記以外の場合 → 上記のMinimalインストールやカスタムビルドなどが考えられます。

ハマった点やエラー解決

Scenario 1: serviceコマンドは存在するが、特定のサービスが見つからない

  • 原因: /etc/init.d/ ディレクトリに、そのサービスに対応するinitスクリプトが存在しない。
  • 解決策:
    1. まず、そのサービスがそもそもインストールされているか確認します。
    2. インストールされている場合、そのサービスがsystemd（systemctl）で管理されるのか、それともSysVinit（service）で管理されるのかを調べます。
    3. もしsystemdで管理されるべきサービスなのにserviceコマンドでしか操作できない環境であれば、systemdの導入を検討します。
    4. もし、systemd環境でsystemctl status <service>でエラーになる場合は、/usr/lib/systemd/system/ や /etc/systemd/system/ ディレクトリに、そのサービスの.serviceファイルが存在するか確認し、必要であれば再インストールや手動での作成を検討します。

Scenario 2: systemctlコマンドもserviceコマンドも存在しない

  • 原因: 上記の「古いLinuxディストリビューションの使用」や「Minimalインストール」の可能性が高いです。
  • 解決策:
    1. まず/proc/1/exeでinitプロセスの種類を確認し、SysVinitが動いているなら/etc/init.d/スクリプトを直接操作します。
    2. それでも不便な場合や、よりモダンな管理をしたい場合は、systemdのインストールを検討します。ただし、前述の通り、systemdへの移行はシステム構成に大きく依存するため、慎重な調査と実施が必要です。CentOS 6のような古いシステムでは、yum install systemdだけでは不十分で、systemdをデフォルトのinitシステムとして起動させるための追加作業（ブートローダー設定など）が必須となります。

Scenario 3: yum install systemd が失敗する（依存関係エラーなど）

  • 原因: OSのバージョンが古すぎる、あるいは既に別のinitシステムに深く依存しているため、systemdの導入が困難な場合。
  • 解決策:
    1. OSのアップグレードを検討: 可能であれば、より新しいバージョンのOSにアップグレードすることを強く推奨します。これにより、systemdが標準で導入され、管理が容易になります。
    2. 代替手段に留まる: systemdの導入が現実的でない場合は、/etc/init.d/ スクリプトや、特定サービスのバイナリ（例: apachectl, nginxコマンド）を直接操作する方法に留めます。
    3. サードパーティ製ツールの検討: 非常に限定的ですが、特定の用途に特化したサービス管理ツールが存在する可能性もあります。しかし、標準的な方法ではないため、利用には注意が必要です。

まとめ

本記事では、Linux環境でsystemctlやserviceコマンドが利用できない、という直面しやすい状況に対して、その原因と具体的な代替手段、そしてsystemdを再導入する方法について解説しました。

  • serviceコマンドがない場合: SysVinit環境では、/etc/init.d/ディレクトリにあるinitスクリプトを直接実行することでサービスを管理できます。
  • systemctlコマンドもserviceコマンドもない場合: OSが非常に古いか、Minimalインストールであることが多く、まずは/proc/1/exeでinitプロセスを確認し、/etc/init.d/スクリプトを直接操作するなどの方法を試します。
  • systemdの再導入: より現代的なサービス管理を目指す場合は、systemdのインストールと有効化が有効ですが、OSのバージョンに依存した慎重な手順が必要です。

この記事を通して、systemctlやserviceコマンドがない状況でも、Linuxサーバーのサービス管理を諦める必要はないということをご理解いただけたかと思います。今後は、各initシステム（SysVinit, systemd）のより詳細な仕組みや、カスタムinitスクリプトの作成方法、さらにはDockerなどのコンテナ技術におけるサービス管理についても記事にする予定です。

参考資料