Ian Jackson - 09.08.19, 11:27:31 CEST:
> Ondřej Surý writes ("Re: Please stop hating on sysvinit"):
> > On 9 Aug 2019, at 09:22, Martin Steigerwald <mar...@lichtvoll.de>
> > wrote:
> > > Actually as a user of my services I do not even notice any
> > > difference, so for me it is: What is actually the point of
> > > starting them on demand?>
> > Unprivileged access to port < 1024. The socket-activated services
> > can start as user since the port binding is done by the systemd,
> > not the daemon.
> This is a good reason to use inetd or socket activation, indeed.
>
> But there are other ways. Many traditional daemons can start as root
> and drop privileges. And of course there is authbind.[1]
[…]
I agree that this is a good reason.
What about about files it might still need to create with root and
whatever other initialization thing it needs to do as root?
And yes, there are other ways and they appear to be used already:
On my sysvinit server I see all but one Postfix process ("master")
running as user 'postfix'.
For dovecot I see:
% ps -eo user,pid,cmd | grep "[d]ovecot"
root 2579 /usr/sbin/dovecot -c /etc/dovecot/dovecot.conf
dovecot 2587 dovecot/anvil
root 2588 dovecot/log
root 2602 dovecot/config
dovecot 2824 dovecot/stats
dovecot 24499 dovecot/auth
root 24821 dovecot/lmtp
root 24839 dovecot/lmtp
root 24850 dovecot/auth -w
root 24851 dovecot/auth -w
Is that any different than what is happening with Systemd?
And what would be the benefit for Systemd opening the port instead of the
process doing it itself and dropping the port.
I see the following advantages:
- standardization
- reduction of code duplication
I see the following disadvantages:
- tightening the dependency between the service and a *certain* service
manager, unless socket activation happens to be a standard that is
agreed on by several service manager upstreams
- added complexity and thus statistically a higher probability for bugs
within the service manager
- reduced portability unless socket activation happens to be a standard
that is agreed on by several service manager upstreams in different UNIX
like systems.
Thing is, we could go on like this endlessly. It is always easy to find
argument pro and contra and in the end it is much ado about nothing… or
well much ado about personal taste.
All what I am wondering about is:
Is Debian as a project big enough to allow people to have different
taste? All what I am wondering is: Is Debian as a project big enough to
allow people to agree to disagree?
I believe, within a few limitations that are woven into the current
approach of how packages work, it can be big enough to allow for this.
Yes, it is not easily maintainable to have util-linux both with and
without libsystemd dependency, but this is what Devuan does handle just
fine. And yes, Debian developers have no obligation to keep help keeping
the difference between Debian and Devuan as minimal as possible… however…
aside from those technicalities…
I understand that one goal of Debian is to be a universal operating
system. Using Debian with sysvinit or runit seems to be a use case for
some… and AFAIK it was and is still the project wide agreement to allow
for different service managers or initialization systems.
But before I keep repeating myself: Just again… I'd recommend and aim
myself to just let go of any hatred. If I look through it, it is not
real to begin with. How about some compassion and forgiveness for each
apparent other and one self instead?
I dug a lot into Systemd to update my Linux training material. In my
courses I tell people look: this and that I like and this and that I do
not like and your mileage may wary and you have a choice on how to deal
with that unless you must use some kind of some distribution with
enterprise backed support and documentation like RHEL or SLE.
I know both. I know quite a bit about Sysvinit and Systemd. It is not
black and white for me. My personal preference after a long period of
using Debian with systemd was just to switch back to sysvinit after
several experiences where I had to deal with an issue I would not have
had with Sysvinit. I do not remember them all right now but some had to
related with a quite limited rescue environment, with an fstab without
"nofail" for non critical filesystems and some other stuff. And after I
found for myself that yeah a lot of stuff that Systemd provides is nice…
but I found myself not really needing it. My time with Amiga taught me
the beauty of simplicity. And this is just kind of still with me.
BTW: We found in a training that we can easily bring Systemd to an halt
by just sending a couple of SIGILL signals to it while Sysvinit is
completely oblivious to that signal. If I remember correctly this still
worked with a Systemd in Debian Buster and it needed to be about 4-5
SIGILL's, maybe less:
while true; do echo -n "." ; kill -ILL 1; sleep 0.5 ; done
as root should be enough to easily reproduce the issue. It brought down
the system completely whenever we tested it.
I never actually cared to file a bug report, part of the reason is that I
just would not like having to deal with any upstream reaction to it. If
anyone here chooses to verify that finding and if able to reproduce of
course feel free to go ahead. Otherwise I would not have shared it here.
Just keep me out of any discussions on Github about any upstream bug you
might file. How upstream developers sometimes reacted to bug reports has
been another part of the reason why I switched away from Systemd.
However, I really do think it should not be that easy to bring down PID
1 no matter whether it is a wise idea to send SIGILL to PID 1 or not. So
it would be good to file an upstream bug report IMHO.
--
Martin
