Debian 不安定コンテナを起動しました。当初、コンテナ内のシステムが登場しましたrsync.service: Cannot add dependency job, ignoring: Unit rsync.service is masked
。
rsyncパッケージが削除されたため、rsync.serviceが自動的にブロックされると確信しています。パッケージを再インストールすると再公開されました。
- この動作に関するドキュメントはありますか?
- Debian でこれらの動作に直面したときに systemd に警告を発行させるクラッシュは何ですか?
- 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
。 これは これはrsyncパッケージに関連するエラーです。サービスファイルはパッケージにありますが、systemctl disable
、シンボリックリンクが削除されたファイルを指している場合、そのファイルは現在削除されていないためです。rsync
サービスを参照するrpmスクリプトはパッケージにありますrsync-daemon
。