On 02/01/17 10:00, Nico Kadel-Garcia wrote:
> On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth
> <[log in to unmask]> wrote:
>> On 01/01/17 01:28, jdow wrote:
>>> systemd sucks dead bunnies through garden hoses - chiefly due to nearly
>>> totally absent documentation.
>> Seriously?
>>
>> $ locate systemd | grep /usr/share/man/ | wc -l
>> 145
> Number of man pages is not the same as good documentation. 

Fair point.  But from all my experience with the man pages in systemd,
they are well written and provides all the information you do need to
understand what the various unit files does.  But as always, YMMV.

> Part of the
> difficulty of documenting systemd is its sprawl into different systems
> that have nothing to do with daemon management itself, including
> logging, DHCP, network configuration, automounting,

I'd say that logging has everything to do with service management.
upstart and the prior alternatives did very bad logging of services
starting up at boot, where I just too often lost important details
services wrote directly to the console and was never caught in any log
files.  Systemds journal captures even those.

Automounting may not be strictly daemon (or service) management, but
again I find the documentation (systemd.automount and systemd.mount man
pages) providing the information I need.  And the autofs service is a
very different chapter, which is a daemon managed by systemd.

But again, all of these new approaches can in the very most cases be
disabled (or disables itself) if you install the packages you're used
to.  F.ex. all my EL7 systems run with rsyslogd and the journal, without
any issues.  All the servers run ntpd which disabled chronyd.  And the
network confniguration have not arrived in EL7 yet, so for that I don't
worry yet.

> and more recently
> trying to replace SELinux with "brilliant security changes!!!" such as
> the ill-fated "KillUserProcess" tool that kills all background
> processes when a user logs out and which breaks nohup, screen, and
> tux.

That's more a matter of perspective.  On some systems I do see that
KillUserProcesses= is not a good idea.  But on most systems I've used,
it is a very good idea that user sessions are properly cleaned up and
don't leave stray processes running in the background.  And the proper
way to tell systemd's login manager that a user is going to have some
processes running after logout, there is 'loginctl enable-linger'.  If
you dislike it, you can always switch back to the old behaviour, by
setting KillUserProcesses= in logind.conf yourself.

Complaining that systemd changes the behaviours of the old way of doing
things are less than useful when considering all the various issues with
how systems where managed before systemd.  From my perspective, systemd
is far more capable of managing a system, both in short and long time
perspective, doing things how they should have been done in the
beginning.  And yes, daemontools had some good merits, and I see that
systemd actually brings in several of the ideas from there (but not
implemented in the same way, far from it).

Unfortunately, it too often seems that people complain about systemd
more due to the personality of the core systemd developers and their
bruteforce approach of introducing systemd into Fedora 6-7 years ago,
more than actually looking at the benefits systemd provides in a system
today.  Holding grudges against people for their behaviour instead of
trying to get a grip of their overall goal is not really much helpful in
the long run.


-- 
kind regards,

David Sommerseth