First let me thank you Holger for addressing the issue and resolving
it. It is much appreciated! Things are once again in a happy state.
Michael Biebl wrote:
> Bob Proulx 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.
Right.
> 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.
No disagreement there. Not sure why you are mentioning this though.
> 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
Again I am not sure why you mention this here. Sure there are many
things that one may do. But why do them? Logrotate scripts have
developed to the state they are are in because then they work for
everyone. That includes calling invoke-rc.d when processes need the
action of reload or restart or try-restart. That's a good thing. And
it is not a burden. And then it works for everyone. That's a good thing!
> Bob Proulx wrote:
> > In my case I noticed because I don't have any init system installed
> > within reach at all. It's a very special case. But useful. So for
> > me on the upgrade it produced errors from calling systemctl and not
> > finding it. So I knew immediately. Which was a useful mine-canary.
You did not quote that but that was in the previous message. The
policy-rc.d layer handles this case okay no problem.
> 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.
It has evolved to be the standard operating practice there and I think
the policy reference cited earlier specifies it. Why? Because it
solves a problem. It's not a burden. It provides flexibility by
abstracting the interface into the policy layer. That's a good thing.
> 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
Yes. And all of those deserve a bug report when found.
> - calling invoke-rc.d foo <action>
That one works for everyone though.
> It's a shortcoming of the debian policy that is not specified, what
> interface to use in such integration hooks/points.
https://www.debian.org/doc/debian-policy/ch-opersys.html#running-init-scripts
Though that was written in the before time I think it is still good
policy. I would be sad to see this useful interface broken.
> Using invoke-rc.d instead of systemctl in munin-node is imho not justified
> by policy.
How are you injured by using the invoke-rc.d policy layer?
Meanwhile... Certainly *my* chroots which I have been using and wish
to continue to use are definitely injured by the hard coded use of
systemctl there.
> One could argue that invoke-rc.d gives you some kind of init independence,
> but that is merely accidental.
And yet here we are crusading to stop even "accidental" init
independence. Sad.
> And in a chroot, cron would not be running anyway, so the point about
> postrotate scripts being called is kinda moot.
There is often good reason to run cron and logrotate in chroot
containers. Log trimming for one. But also for all of the other
purposes too. I often have many chroot containers running on a system
and each of them of this particular type will have cron running in the
chroot. It is a valid use case. Keeping things all contained in one
place in the guest is valid and the method I prefer.
I use all of chroots, control groups, namespaces, linux-containers,
virtual machines, and other methods. They each have their uses with
pros and cons. (I say this because I want to avert the suggestion
that I am doing it wrong by using a chroot and that I am not aware of
the many different technologies available. I am both aware of them
and make use of them. That does not invalidate the chroot use case.)
Bob
