systemdサービスファイルを作成した後は、initサービスを有効にすることはできません。

systemdサービスファイルを作成した後は、initサービスを有効にすることはできません。

systemd環境でsysVinitサービスを起動すると正常にオンラインにならない問題を解決しています。/etc/systemd/system/そのサービスにサービスファイルがないかオーバーライドすると、自動的に正しく起動されることがわかりました。この場合、systemdはシステムに存在する「レガシー」sysvinitスクリプトを読んで起動スクリプトを動的にロードする必要があることを理解していますが、これについては100%明確ではありません。

私が混乱させているのは、そのサービスのsystemctlにedit --fullオプションを渡すとフラットファイルが作成され、/etc/systemd/system/そのサービスが起動時に自動的に開始されないことです。編集オプションを使用してオーバーライドを追加しようとすると、サービスが開始されないようです。

必要に応じて以下の例をご覧ください。

システムの動作方法の例

この場合、「ProgramExample」というサービス(Centos)には、/etc/init.d/programexampleにinitスクリプトがあります/etc/rc.d/init.d/programexample

# ls -l /etc/rc.d/init.d/programexample
-rwxr-xr-x. 1 root root 2264 Mar 29 14:11 /etc/rc.d/init.d/programexample

サービスファイルがありません/etc/systemd/system/

# ls -lh /etc/systemd/system/programexample.service
ls: cannot access /etc/systemd/system/programexample.service: No such file or directory

この構成の Systemctl 状態出力は次のとおりです。

# systemctl status programexample.service
● programexample.service - LSB: Start Program Example at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; bad; vendor preset: disabled)
   Active: active (exited) since Wed 2017-03-29 15:53:06 CDT; 14min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1297 ExecStart=/etc/rc.d/init.d/programexample start (code=exited, status=0/SUCCESS)

Mar 29 15:53:05 centos7-box systemd[1]: Starting LSB: Start ProgramExample at boot time...
Mar 29 15:53:05 centos7-box su[1307]: (to programexample) root on none
Mar 29 15:53:06 centos7-box programexample[1297]: ProgramExample (user programexample): instance name set to centos7-box
Mar 29 15:53:06 centos7-box programexample[1297]: instance public base uri set to https://192.168.0.148.programexample.net/programexample/
Mar 29 15:53:06 centos7-box programexample[1297]: instance timezone set to US/Central
Mar 29 15:53:06 centos7-box programexample[1297]: starting java services
Mar 29 15:53:06 centos7-box programexample[1297]: ProgEx server started.
Mar 29 15:53:06 centos7-box systemd[1]: Started LSB: Start ProgramExample at boot time.

上記の設定を使用すると、/ etc / systemd / system /にファイルを作成/配置する必要がなく、ProgramExampleサービスが自動的に正常に起動することができます。

systemctl edit --full一度(または1つだけ)を使用:edit

systemctlに編集内容を渡した後、次のことを観察しました。

  • フラットファイルまたはオーバーレイディレクトリは/etc/systemd/system/に配置されます。
  • 問題のサービス(この場合ProgramExample)は起動時に起動できません。
  • systemctl を使用してそのサービスを「アクティブ化」することはできません。

この構成のSystemctlステータス出力(編集後):

# systemctl status programexample.service
● programexample.service - LSB: Start ProgramExample at boot time
   Loaded: loaded (/etc/rc.d/init.d/programexample; static; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

/etc/systemd/system/オプションを使用したときに作成および配置されるサービスファイルedit --full

# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/rc.d/init.d/programexample
Description=LSB: Start ProgramExample at boot time
Before=runlevel2.target
Before=runlevel3.target
Before=runlevel4.target
Before=runlevel5.target
Before=shutdown.target
Before=adsm.service
After=all.target
After=network-online.target
After=postgresql-9.4.service
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/rc.d/init.d/programexample start
ExecStop=/etc/rc.d/init.d/programexample stop
ExecReload=/etc/rc.d/init.d/programexample reload

ここで何が起こっているのでしょうか? / etc / systemd / system /および/またはサービスオーバーレイディレクトリにフラットサービスファイルがない場合、systemdはそのサービスのinitスクリプトからこの情報を動的に読み取ることを修正しますか? /etc/systemd/system/でサービスファイルを編集し、デフォルトファイルをそのままにする操作を数回試しましたが、自動起動が機能しないか、サービスが「アクティブ」状態に移行しません。

互換性と並行性の理由から、systemdに依存してinitスクリプトLSBヘッダーから読むよりも、systemd構成用のsystemd .serviceファイルを提供する方が良いと思います。ただし、systemdによって生成されたデフォルトファイルは起動しないか、他の多くのファイルと連携しません。一緒に試した .service ファイルをより簡単に繰り返すことができます。

ベストアンサー1

これで問題は、systemd-sysv-generatorによって自動的に生成されたサービスファイルにWantedByオプションを含むインストール部分がないことです。サービスを正しく有効にするために生成されたファイル/etc/systemd/system/programexample.serviceに以下を追加しました。

[Install]
WantedBy = multi-user.target

その後を追って走った

systemctl daemon-reload

systemdが私のサービスファイルを読んでいることを確認してください。

今、私のサービスが実際に「アクティブ」になるどこかにシンボリックリンクされているという適切な通知を受け取ります。

[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.

このリンクサービスファイルをよりよく理解するのに役立ちます。

systemd-sysv-generatorにデフォルトでWantedByオプションを持つインストールセクションが含まれていないことは気に入りません。 systemdがLSBヘッダーを動的に読み込み、起動時にサービスを正しく開始できる場合は、それに応じてサービスファイルを生成しないのはなぜですか?私はsystemdが成長に直面すると予想されると思います。

2020年7月7日更新:

Debian Busterで作業し、SysVInitレガシーサービスを有効にしようとしたときに、2017年にこの問題を処理するときに時間を節約できると思う次のような素晴らしいメッセージを受け取りました。

Synchronizing state of programexample.service with SysV service script with 
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units). 
This means they are not meant to be enabled using systemctl. 
Possible reasons for having this kind of units are:

• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or 
.requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

おすすめ記事