tito via Dng writes: > On Sun, 13 Jun 2021 19:41:28 +0900 > Olaf Meeuwissen via Dng <dng@lists.dyne.org> wrote: > >> d...@d404.nl writes: >> >> > Not hindered by any knowledge about system programming I am >> > wondering how much work it would be to implement a socket >> > activation interface without systemd. Although what I read about >> > its design it is unnecessary complicated. Using a tinylog component >> > in systemd until syslogd is loaded is one example of such >> > complicating solution. >> > >> > Has anyone invested some time in analyzing systemd's socket >> > activation and mind to share it on this list or in email? >> >> When I read[1] >> >> Cockpit itself doesn’t eat resources or even run in the background >> when you’re not using it. It runs on demand, thanks to systemd >> socket activation. > > Hi, > would it be possible to start it with a initscript and let it run? > and totally ignore this socket stuff?
Probably, but then cockpit would "eat resources". >> all I could think of was that inetd and xinetd have been doing that >> job for a (couple of) decade(s) already. Of course, running (x)inetd also eats resources but the question then becomes whether running systemd consumes more resources then (x)inetd plus your choice of init. # That's assuming you're willing to consider running systemd to begin # with ;-) >> The only other mention of systemd on that webpage is one in a longish >> "subset of tasks you can perform on each host running Cockpit" that >> says you can >> >> Inspect and interact with systemd-based services > > Having briefly looked and grepped the source when I removed webmin > from my systems (when it was backdoored) the biggest problem > is that cockpit calls systemctl, hostnamectl and friends directly so > without systemd functionality is crippled as no alternative functions > are provided. It could be an idea and helpful for devuan mastering > the systemd dependency epidemic to create some wrappers for > this systemd binaries as compatibility layer rather than try to modify > every program out there that thinks it needs to depend on systemd, > that way you just modify the dependencies of the cockpit package, > resign it and you are good to go. While I can understand your line of thinking, I think it's a bit of a slippery slope. If projects decide to throw in their lot with systemd (as in not accepting patches to cater to non-systemd setups), I think they deserve to be plonked by distributions that don't support systemd. # FTR, I have no sympathy for cockpit. A (remote) command-line suits me # just fine. Folks not comfortable with that shouldn't be administering # "servers" to begin with, IMNSHO. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng