yum updateRHEL 7.4の後でサービスを再起動しようとしています。systemctlを使用してすべてのサービスを再起動できましたが、そこneeds-restartingからyum utilssystemd自体も再起動する必要があることがわかりました。
# needs-restarting
1 : /usr/lib/systemd/systemd --system --deserialize 21
systemdサーバーを再起動せずに再起動できますか？
のいくつかの言及を見つけましたsystemctl daemon-reloadが、これによりニーズの再起動リストから消えることはありません。
回答:
デーモンを再起動するには、次を実行します
systemctl daemon-reexec
これはマンページに記載されていsystemctlます：
systemdマネージャーを再実行します。これにより、マネージャーの状態がシリアル化され、プロセスが再実行され、状態のシリアル化が再度解除されます。このコマンドは、デバッグとパッケージのアップグレードを除いてほとんど役に立ちません。時には、それはヘビー級として役立つかもしれません
daemon-reload。デーモンが再実行されている間、ユーザー設定のためにリッスンしているすべてのソケットsystemdはアクセス可能なままです。
残念ながらneeds-restarting、systemd実際に再起動したことを判断することはできません。systemd execs自身を再起動します。プロセスの開始時間はリセットされません。しかしneeds-restarting、実行可能ファイルの変更時間をプロセスの開始時間と比較して、プロセスを（特に）再起動する必要があるかどうかを判断し、その結果、常にsystemd再起動する必要があると見なします... systemd本当に再起動する必要があるかどうかを判断するには、あなたはの出力を確認することができますlsof -p1 | grep deleted：systemdライブラリ、使用しlibsystemd-sharedている場合は、同じパッケージで出荷されるため、デーモンと一緒にアップグレードされ、systemdニーズは、ライブラリの削除バージョンを使用して、それを見ることができます再起動します。lsof削除されたファイルが表示されない場合は、systemd再起動する必要はありません。（ありがとうヒントはジェフ・シャラー！）
systemdDebianおよび派生物をアップグレードするたびに使用されるため、十分にテストされています。また、かなり簡単です（探してくださいdo_reexecute）。
lsof -p1 | grep deleted次の出力を実行しようとすると、生成されlsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incompleteます。読むと（unix.stackexchange.com/questions/171519/…）、rootでさえアクセスできないようです。代替手段は何lsof -p1 | grep deletedですか？
私の場合、アップグレードsystemdしたばかりでsystemctlコマンドが失敗していました。
# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied
ただし、initマンページによると、SIGTERMPID 1として実行されているデーモンに送信することで同じことができます。
kill -TERM 1
これによりデーモンがリロードされ、その後すべてのsystemctlコマンドが再び機能し始めました。
daemon-reexecさえして動作するようになっているsystemdとして、PID 1