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