On 02/01/17 10:00, Nico Kadel-Garcia wrote: > On Sun, Jan 1, 2017 at 5:19 PM, David Sommerseth > <[email protected]> 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
