SystemdドロップインがPIDファイルの作成に失敗する

11

パスにsystemd-machinedのドロップインがあります/etc/systemd/system/systemd-machined.service.d/10-machined-pid-file.conf。走るsystemctl status systemd-machinedと線が見える

Drop-In: /etc/systemd/system/systemd-machined.service.d
       └─10-machined-pid-file.conf

しかし、/ var / run /にPIDファイルがありません。これは私のドロップインに基づいています：

[Serivce]
PIDFile=/var/run/machined.pid

そのPIDファイルを作成するときに問題は発生しないはずです。何か足りないものはありますか？

files systemd pid

— クリスチャン・グラボウスキー
ソース

18

このPIDFile=設定ではPIDファイルは作成されません。それは、サービス自体がやるべきことであり、過去40年間と同じです。むしろ、このオプションは既存のPIDファイル（存在する場合）を見つける場所をsystemdに指示します。systemdは独自のcgroupにサービスを保持し、それらを追跡するためにPIDファイルを必要としないため、ほとんどの場合、それはまったく必要ありません。ただし、サービス自体のクリーンアップに失敗した場合、systemdはサービスの終了時にPIDファイルを削除します。

ドキュメントから：

このデーモンのPIDファイルを指す絶対ファイル名を取ります。Type=がに設定されてforkingいるサービスでは、このオプションの使用をお勧めします。systemdは、サービスの起動後にデーモンのメインプロセスのPIDを読み取ります。systemdは、ここで構成されたファイルに書き込みませんが、サービスがまだ存在する場合は、サービスのシャットダウン後にファイルを削除します。

— マイケル・ハンプトン
ソース

説明をありがとう。私の場合、playframeworkはプロジェクトのルートフォルダーにpidファイルを作成しましたが、このプロセス/サービスを停止または強制終了しても「pid」ファイルは削除されませんでした。そのため、「pid」ファイルが原因でプロジェクトサービスを再起動できませんでした。この「PIDFile = / path / to / pid」行をsystemdサービスファイルに追加すると、うまくいきました。サービスが停止または

— 強制

10

残念ながら、systemdはPIDFile=、サービスのユニットファイルに行を指定しても、fork以外のサービスのPIDファイルを作成しません。ただしExecStartPost=、次のような行でカンニングできる場合があります。

ExecStartPost=/bin/sh -c 'umask 022; pgrep YOURSERVICE > /var/run/YOURSERVICE.pid'

— マイク・グリーソン
ソース