Runit-services RFS
Martin Steigerwald
martin at lichtvoll.de
Tue Nov 22 10:13:53 GMT 2022
Hi Lorenzo.
Lorenzo - 22.11.22, 01:47:34 CET:
> Thanks for your help testing this package!
You are welcome! Thanks for developing it!
> On Sat, 19 Nov 2022 15:37:04 +0100
>
> Martin Steigerwald <martin at lichtvoll.de> wrote:
> > I am now testing runit-services 0.5.0 from experimental (on Devuan
> > Ceres):
I found two issues meanwhile, I can report them via bug tracker, but as
I use Devuan by default it would be the Devuan bug tracker, unless I
install Debian reportbug into some chroot which would reduce the
usefulness of automatic debug data or from source or change configuration
of Devuan reportbug to send to Debian Bug Tracker.
1) Major issue: Once I install runit-services Network Manager is not
started on boot automatically anymore. I tried it on two laptops. On one
I removed runit-services again. Then Network Manager started again on
next reboot. As I use Devuan network-manager package still has the init
script /etc/init.d/network-manager. In /var/log/boot I have only:
Tue Nov 22 10:22:22 2022: Starting network connection manager:
NetworkManager.
No error message or so. Starting it manually after boot works okay.
I have no idea why cause your package does not provide a service dir for
it that could fail. Expect maybe that is the reason: Maybe an ordering
issue? As so DBUS not yet up before Network Manager is starting?
Probably would be best to also make a runit service dir for Network
Manager and implement proper dependency handling there.
2) Purging the package on a system with DBUS and SDDM is problematic. It
fails the purge cause it does not like to remove DBUS and SDDM service
directories while DBUS and SDDM are running. Thus the purge operation
fails. It asks to manually stop those services. For SDDM this is easy.
However DBUS just was started again. But maybe if I would have stopped
the Plasma desktop session before and stopped DBUS on a TTY it would
have worked. I bet this could use some explanation for users who for
whatever reason like to remove runit-services again. What I did was just
removing those service directories from /etc/service myself using rm -r.
By the way: Runit did not stop those sddm then, or well at least the
Plasma desktop session was still running.
Of course on a server systems where so far I do not need DBUS and I also
of course do not need SDDM, I bet purging would work okay. This is one
of the major benefits for me with not running Systemd on a server: No
DBUS. This removes quite a bit of privilege escalation attack surface.
> > In case you have any specific tests or things to look out for, let
> > me know.
>
> What do you think about the way the upgrade of services is (not)
> handled?
> Perhaps this is not obvious right now because this is the first
> version of the package, but at each upgrade cpsv will just print a
> warning if a new version of a service is available and it won't
> automatically replace the the old version in /etc/sv/ .
> If the user decides to upgrade the service an extra invocation of cpsv
> is needed.
For a few services I think this would be okay. Of course it would be
more comfortable to be asked whether to upgrade a service. It could even
be in a dialog like needrestart presents. It asks which of the services
to restart after updates in a nice dialog window where you can select
those to be restarted. So it would ask once and the user selects the
services to upgrade.
> Do you prefer some kind of automation, similar to what dpkg or ucf
> provide?
Hmmm, I think dpkg diffing and ucf would not work that well for service
directories. Those mechanisms work on single files.
But might be an option to present some kind of diff. Then of course
update handling would be one by one.
However, I think offering some automation has not really the highest
priority. It is nice to have. Not essential.
> > There some services not yet included in runit-services like
> >
> > ├─sshguard─┬─sshg-blocker───{sshg-blocker}
> > │ ├─sshg-fw-iptable
> > │ ├─sshguard───tail
> > │ └─sshguard───sshg-parser
> >
> > or
> >
> > ├─atop
> > ├─atopacctd
> >
> > ├─vnstatd
>
> I'll look if it's possible to include those services in a future
> version :)
Great!
I think it would be really good to fix the Network Manager not starting
issue. Cause this could hit many desktop users. I know there are other
network management daemons out there, but Plasma desktop works best with
Network Manager. And quite some other desktop environments as well.
I was not happy about Network Manager for a long, long time. Nowadays it
just works for me.
Thank you,
--
Martin
More information about the Debian-init-diversity
mailing list