☰

Debian パッケージを削除すると、systemd サービスが自動的にブロックされ、systemd 警告が発生します。

tag-icon • tag-icon debian systemd
Debian パッケージを削除すると、systemd サービスが自動的にブロックされ、systemd 警告が発生します。

Debian 不安定コンテナを起動しました。当初、コンテナ内のシステムが登場しましたrsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked。

rsyncパッケージが削除されたため、rsync.serviceが自動的にブロックされると確信しています。パッケージを再インストールすると再公開されました。

  1. この動作に関するドキュメントはありますか？
  2. Debian でこれらの動作に直面したときに systemd に警告を発行させるクラッシュは何ですか？
  3. rsyncをインストールするときにブロックすると、この動作が何とか検出され、rsyncを削除して再インストールすると自動的にブロックが解除されないことに驚きました。これはどのように達成されますか？ ？他に微妙な制限はありますか？

パッケージが削除されたことが確認されたら、自動的にパッケージをブロックします。

rsyncが元々インストールされていましたが、今は削除されていることを知っています。マスクを脱いだらこんなに残りました。

$ sudo systemctl status rsync
● rsync.service - LSB: fast remote file copy program daemon
   Loaded: loaded (/etc/init.d/rsync; generated; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

$ # reset status of all systemd services
$ # DO NOT TRY THIS COMMAND INSIDE A REAL, NON-CONTAINER SYSTEM...
$ # IT DOES NOT GO WELL.
$ sudo systemctl isolate default.target

$ sudo systemctl status rsync
● rsync.service - LSB: fast remote file copy program daemon
   Loaded: loaded (/etc/init.d/rsync; generated; vendor preset: enabled)
   Active: active (exited) since Wed 2017-06-07 11:35:27 BST; 1s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 432 ExecStart=/etc/init.d/rsync start (code=exited, status=0/SUCCESS)
   CGroup: /machine.slice/machine-unstable.scope/system.slice/rsync.service

Jun 07 11:35:27 unstable systemd[1]: Starting LSB: fast remote file copy program daemon...
Jun 07 11:35:27 unstable systemd[1]: Started LSB: fast remote file copy program daemon.

この出力は誤解を招く可能性があります。何も変更しなかったため、Debian は起動しませ/etc/init.d/rsyncんでした。 （この場合、initスクリプト自体は自動的に終了しますが、systemdは上記のログメッセージに似た開始メッセージで始まると思います。）rsync --daemonしたがって、マスキングはここで役に立ちます。RSYNC_ENABLE=false/etc/default/rsync

（パッケージを削除しても/etc/init.d/rsyncが残っているのは、initscriptがユーザーが編集できる設定ファイルと見なされるためです）

rsyncを再インストールすると、rsync.serviceがブロック解除されることがわかりました。削除すると、rsync.service が再びブロックされます。

rsyncをインストールしてブロックし、rsyncをアンインストールして再インストールすると、rsyncはブロックされたままになります。

apt-get remove --purge rsync残りの構成ファイルを含む完全除去を使用すると、マスクが除去されます。

etckeeperをインストールしたので、完全に削除すると /etc/systemd/system/multi-user.target.wants/rsync.serviceマスク（/etc/systemd/system/rsync.service- > /dev/null）も削除されるだけでなく、etckeeperも削除されることがわかりました。これらのファイルはすべてパッケージ（dpkg-query -L rsync）に属していないため、これらの削除はパッケージスクリプトによって引き起こされたようです。

ソフトウェアバージョン

最新の Debian 不安定コンテナ。この質問は、ストレッチがリリースされる直前に提起されました。

ホストはsystemd-containerバージョン231-15.fc25を使用します。

システムメッセージ「無視：ユニットrsync.serviceがブロックされました」の追加コンテキスト

$ sudo systemd-nspawn -b -D unstable
Spawning container unstable on /home/nspawn/unstable.
Press ^] three times within 1s to kill container.
systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Debian GNU/Linux 9 (stretch)!

Set hostname to <unstable>.
Failed to install release agent, ignoring: File exists
rsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.

ベストアンサー1

この動作に関するドキュメントはありますか？

記録されました。ポインタなぜこれは、後で別の場所に移動されたファイルへのコミットメッセージで見つかりました。

rsyncをインストールするときにブロックすると、この動作が何とか検出され、rsyncを削除して再インストールすると自動的にブロックが解除されないことに驚きました。これはどのように達成されますか？ ？他に微妙な制限はありますか？

注意深く見ると、まだ見つけることができます。ソース履歴。それは次につながります質問これは、systemdでマスキングを使用すると、System V initスクリプトをできるだけ効果的に処理できることを確認します。

Tangent：これの必要性を排除する実装されていない提案があります。＃749400 - dh_installinit：パッケージを削除するときにinitスクリプトを無効にします。。それは、それが明らかに良い考えだと言うわけではありません。 IIUCでは、ユーザーがスクリプトを有効にしたかどうかを追跡する方法はありません。 （これはシステムV initの各ランレベルの個別の設定です。）

手がかりは私が見つけたパッケージスクリプトにありました/var/lib/dpkg/info/rsync.postrm。

## from /usr/share/debhelper/autoscripts/postrm-systemd :

if [ "$1" = "remove" ]; then
    if [ -x "/usr/bin/deb-systemd-helper" ]; then
        deb-systemd-helper mask rsync.service >/dev/null
    fi
fi

その機能はで説明されています。man deb-systemd-helper「遮断」操作は、サービスが以前に有効/無効になっているかどうかを維持し、「遮断解除」時にその状態に正しく戻ります。 rsync.postinst

## from /usr/share/debhelper/autoscripts/postinst-systemd-enable :

# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask rsync.service >/dev/null || true

Fedora Linux（バージョン25）はこの動作を実装しません。おそらく、システムV initをサポートせずにレガシーinitスクリプトを完全に削除するポリシーがあるからです。移行中にこの問題をどのように処理するかはわかりませんが、機能的な問題を引き起こすことなく無視できます。

Debian でこれらの動作に直面したときに systemd に警告を発行させるクラッシュは何ですか？

一般的にブロック可能なサービスは少し不審だと思いますか？

rpmベースのディストリビューションは、initscriptsを有効にしようとしないか、試していないようです。checkconf --del削除すると実行されるからです。https://www.cyberciti.biz/faq/centos-rhel-suse-rpm-see-installation-uninstallation-scripts/

最新のFedora rpmにも同様のコードがあります。

$ rpm -q --scripts rsync
...
    # Package removal, not upgrade 
    systemctl --no-reload disable --now avahi-daemon.socket avahi-daemon.service > /dev/null 2>&1 || :
...

rsync-daemonを削除しても削除されないことがわかったので、これを見ました /etc/systemd/system/multi-user.target.wants/rsyncd.service。 これはsystemctl disable、シンボリックリンクが削除されたファイルを指している場合、そのファイルは現在削除されていないためです。 これはrsyncパッケージに関連するエラーです。サービスファイルはパッケージにありますが、rsyncサービスを参照するrpmスクリプトはパッケージにありますrsync-daemon。

おすすめ記事