tito via Dng writes:

> On Sun, 13 Jun 2021 19:41:28 +0900
> Olaf Meeuwissen via Dng <dng@???> wrote:
>
>> dng@??? 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