On Thu, 5 Oct 2023 15:45:38 -0600 Bob Proulx <b...@proulx.com> wrote:
Holger Levsen wrote: > Bob Proulx wrote: > > The introduction of systemctl is problematic especially when used in > > chroots. > > systemctl handles chroots, so can you elaborate on this?The policy-rc.d layer was created so that dpkg upgrading packages in chroots don't start daemons in the chroot that might be installed in the chroot but for which we don't want them to be running in the chroot. Unless we do. In either case we can control that using the policy-rc.d layer which is entered through the invoke-rc.d command. Therefore packaged actions such as from postinst and logrotate.d and should call through invoke-rc.d which might do nothing if policy-rc.d has been configured for them to do nothing. So that upgrading packages in a chroot won't start daemons there.
That so far is correct. The policy-rc.d/invoke-rc.d layer was designed having the package installation phase in mind, i.e. the use case for invoke-rc.d are maintainer scripts.
It was not meant as a general abstraction layer to start services, especially during boot, and also not during runtime outside a package installation context.
As you correctly noticed, in a chroot, you don't really want start any services. But for systemctl that is not an issue:
# systemctl start rsyslog Running in chroot, ignoring command 'start' # echo $? 0
[[Aside: Strangely the policy-rc.d layer controls a running system but not a booting system. An init system booting ignores the policy-rc.d layer entirely. I have seen systems, mostly virtualized, incorrectly configured with a policy-rc.d that prevents upgrades from (re)starting daemons but that boot and reboot okay. But then upgrades don't restart daemons due to the mistaken configuration. I think that is a hole in the design but a minor one that mostly is never encountered. Except I encountered it. Too funny!]]
As I explained above, the use case of policy-rc.d/invoke-rc.d is the context of the package installation, i.e. maintainer scripts.
That invoke-rc.d is used in hook scripts like logrotate is imho a misuse, as it was never designed with that use case in mind.
If you look more closely, you will find, that e.g. the postrotate scripts in logrotate uses a variety of approaches:
- calling /etc/init.d/foo <action> - calling service foo <action> - calling systemctl <action> foo - calling invoke-rc.d foo <action>It's a shortcoming of the debian policy that is not specified, what interface to use in such integration hooks/points.
Using invoke-rc.d instead of systemctl in munin-node is imho not justified by policy.
One could argue that invoke-rc.d gives you some kind of init independence, but that is merely accidental.
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
