
Escape from systemd - ingve
https://davmac.wordpress.com/2017/06/14/escape-from-system-d/
======
atonse
I get the impression that OP seems to just be abandoning systemd to build
another... systemd. So it seems like not-invented-here syndrome.

I don't really know about any of the drama surrounding systemd but I've liked
using it so far. It's easily the most attractive feature in Ubuntu 16.04 LTS.

Using journalctl for logs is nice because I don't have to keep looking around
for where logs are stored and then tail them. But then again, I don't worry
about log rotation and things like that. My guess is that journalctl takes
care of it.

I'm sure I've barely scratched the surface of all the things it can do (like
auto-restarting daemons, some security stuff, etc).

Am I the exception? Can't be so, if most linux distros have adopted systemd.

~~~
phil21
The basic summary is basically: Developers love systemd, it's much more
"developer friendly" and the way it's laid out makes sense to them (e.g. your
love of journalctl, which is bizzaro-world for me). No more thinking about
ugly operating systems and those silly details!

Old school sysadmins and those who actually get their hands dirty with Linux
systems under the hood despise it for what it is. It's the windowsfication of
Linux, in my - and many others - opinions. A giant PID 1 that controls
everything, re-implementing such basics as ntp and rm, is imo entirely anti-
unix-like.

Systemd is _great_ until it breaks. Once it breaks though, good luck. They've
re-invented the wheel multiple times over, and as time goes on more and more
things become part of monolithic systemd. If you do happen to find a weird
bug, prepare to get yelled at and be forced to vigorously defend your bug
report. The joke in the office is when Pulseaudio support gets added.

~~~
mateuszf
> A giant PID 1 that controls everything

Kernel is also a giant code that controls everything. Is this such a bad
thing?

~~~
Twirrim
The kernel is a component that has a straightforward purpose on a system, and
interferes as little as possible with the actual usage of the system. You
could describe it as "It gets the job done, and stays the hell out of the way"

Even with the kernel there is an element of choice about what parts of it you
do / don't use, e.g. you can use ext4, XFS etc. etc. and even have the choice
of providing kernel modules so you can bolt on ZFS.

The kernel doesn't start to dictate who or what software does DNS resolution,
for example.

systemd keeps taking over more and more control of various aspects of your
system and effectively removing choice by making it hard to use alternatives
because it starts to make assumptions based on the inbuilt versions.

systemd is presenting you with a "one-size-fits-all" scenario. The problem is
one size _never_ fits all.

One of the biggest strengths within the *nix ecosystem has been the
fundamental understanding no two use cases are entirely the same, what works
well for one purpose doesn't work well for others, and choosing the right
software to meet those various purposes is invaluable. It's impossible to make
software that is efficient for every single use case.

The freedom and possibility to choose the right tool for the right task is
essential to designing and building new, innovative, or even just plain old
efficient systems.

~~~
fireflash38
I hear all this, but I never really see examples of it, which would really
help your argument. People hear the 'theoretical', but theoretical doesn't
matter if it never makes it to the practical.

~~~
Twirrim
Okay, so an example:

dnsmas

------
Mister_Snuggles
One thing I've learned to accept about Linux, in general, is that it likes to
go its own way relative to other Unix-like systems.

I've come to accept systemd and actually like it in the sense that, for the
most part, it just works and gets out of my way. The more I learn about
journalctl's options for viewing logs, the more I like it.

The case of Linux going its own way that drives me nuts though is the
replacement of 'ifconfig'. The replacement seems to be in progress, with some
distributions shipping 'ifconfig' in addition to the 'ip' and others only
shipping 'ip'.

EDIT: Other Unixes have also gone their own way with init systems to meet
their own needs. MacOS, for example, replaced initd with launchd. Solaris, way
back in 2005 with Solaris 10, replaced init with SMF[0] which does some of the
things that systemd does on Linux.

[0]
[https://en.wikipedia.org/wiki/Service_Management_Facility](https://en.wikipedia.org/wiki/Service_Management_Facility)

~~~
justinsaccount
> One thing I've learned to accept about Linux, in general, is that it likes
> to go its own way relative to other Unix-like systems

Solaris is Unix. Solaris shipped SMF over a decade ago.

OS X is Unix. OS X shipped launchd in 10.4, back in 2005.

~~~
Mister_Snuggles
In retrospect, "Going its own way" for init systems is a normal thing in the
Unix world. That was actually a terrible example.

At best I could say that the sheer scope of systemd is an example of Linux
going its own way. SMF and launchd, for example, don't change how logging is
done. I don't believe either of those include their own DNS resolver either.

~~~
microcolonel
Granted, the DNS resolver is mainly to support networkd, because apparently
some units might need to resolve a name.

------
Omnius
"I have at least briefly looked at a number of them."

So you are wanting to build a new init system from scratch and you haven't
taken the time to see all the stuff that already exists? I mean if this is
just a project you want to do go for it but if you are seriously trying to
build something for others you know whats out there and why people choose one
over the other beyond just systemd and sys V.

~~~
JdeBP
This is a common fault. Not knowing the history and what has already been done
long since is an error exemplified in this discussion on this very page, in
fact. (One place to start learning from is
[http://blog.darknedgy.net/technology/2015/09/05/0/](http://blog.darknedgy.net/technology/2015/09/05/0/)
.)

But in fairness Davin McCall has done more than most. There is a short writeup
of xyr opinions of various systems, that comes with the Dinit source code. It
gets a number of things wrong about several of the systems and does not go
into as much depth as, say, the Debian Technical Committee members did. But it
does show that M. McCall _has_ at least looked, just as xe states.

------
chasil
A systemd replacement is going to need:

\- an integrated inetd that can launch non-root processes \- ability to
chroot() any application at launch \- inotify capability (path units) \-
consistent scripted application startup and control

Just about any UNIX could really use an init that can do all of that stuff
(even if they don't have cgroups). If you can't, thanks for playing.

------
peterwwillis
You can skip reading this article, it isn't even finished being written, and
is more of a product announcement for a systemd alternative in C++.

------
quigonjinn
There's also GNU Shepherd.

------
oneplane
I wonder why there is no bigger adoption of launchd. It's open source and
works fine. Plenty of BSD's have it available for PID1 usage, and it doesn't
have the feature creep most init replacements seem to grow on.

~~~
Mister_Snuggles
It looks like the FreeBSD folks have been doing some work[0][1] in that area.
Sadly, it doesn't seem like it's actively being worked on at the moment.

FreeBSD's init system works well enough, but there's no question that it could
be better.

[0] [https://wiki.freebsd.org/launchd](https://wiki.freebsd.org/launchd)

[1]
[https://github.com/freebsd/openlaunchd](https://github.com/freebsd/openlaunchd)

~~~
VLM
"FreeBSD's init system works well enough, but there's no question that it
could be better."

Problems or features? I haven't run in to any problems.

From a feature perspective I've run into the system policy bug where the name
of a package has a minimal relationship with the name of the file read in
/etc/rc.conf.d... For example, say you're installing the package named "isc-
dhcp43-server", you need to add a file named /etc/rc.conf.d/dhcpd. Why not a
file named something "obvious" like /etc/rc.conf.d/isc-dhcp43-server ?
Sometimes the names are close enough to be Extremely annoying, like package
name "logstash-forwarder" and /etc/rc.conf.d/logstash_forwarder. Obviously
thats not a bug in the init system, thats a bug mis-using the init system. Or
is that mis_using? Or misusingd-4.2?

Its the kind of issue thats super annoying one time when you write the ansible
script and then you forget about it until next time you're writing an ansible
script to do something else.

I have not run into any lack of features problems with freebsd init. Although
I admit to having run some end user applications (not system stuff) using
supervisord because the end users wanted a pretty web interface for restarting
and logs and stuff.

~~~
Mister_Snuggles
The only 'problem' I've had with FreeBSD's init was when an NFS mount was
unavailable that the machine hung during boot. The mount didn't have anything
required for boot on it, but there were services that depended on those mounts
being there. In retrospect, I probably should have added "failok,-t=10" to
those fstab entries. This one was definitely my fault.

An ideal init system would have known (or been taught) that services x, y, and
z depend on NFS mounts /a, /b, and /c, so the system could have started
mounting those in the background and let other services (like sshd!) start up
as required.

As to your point about the service names, that bugs me as well.

------
nithinm
why the c++ hate in comments? because of the memory leaks?

~~~
oneplane
because of the hidden magic. Linus has a great message on a mailing list
somewhere on this. Basically it boils down to: don't have hidden magic in
important OS parts, it's bad and helps nobody except for people that
explicitly want to use c++.

~~~
antientropic
What "hidden magic"?

~~~
marcosdumay
A C++ line does way more things than a similar looking C line. The developer
may not be aware of all those extra things.

------
Sir_Cmpwn
>I'm making an init system

Awesome, maybe I won't have to!

>C++

Whelp, nevermind.

