>>56826549As a professional sys admin (my team is part of the eCommerce arm for a US wireless telco, we support ~3000 bare metal systems, 85% RHEL 6 and 15% Solaris, and ~500 VMs, all RHEL 6, across 4 data centers in 3 states.) I have done my best to avoid it, my team has done our best to avoid it, and our management has done their best to determine an upgrade path. At this time, it's mostly looking like we'll be sitting on RHEL 6 for some time.
Why?
- logging - centralized logging with plain text logs means that if network fails & your host crashes you still have locally readable plain text logs. Having journald crash (or even worse, having PID 1 crash & uncleanly take down journald thus corrupting the logs) means incomplete (at best) or completely corrupted logs
- login management - our method of user management and permissions does not currently work with systemd. To be fair, this is developed in house, so the blame is not wholly on systemd. On the other hand, it's fully portable and works across Linux (RHEL 6 or earlier, Ubuntu 14.04 provided it's headless, Suse prior to v12), Solaris (5.10), HP-UX, & AIX.
- unit files - all of the people in my team and the majority of admins in the company have been writing scripts for years. Some before the release of SysV. This means that reading, editing, & writing init scripts isn't difficult. Until documentation actually started improving a few years ago, it was leaps & bounds better than writing a unit file. Now, it's still easier because of familiarity.
My opinion: systemd is a fine solution for desktops/laptops/workstations but has NO reason to live on servers. Having improved ACPI functionality & better removable device handling is a solid desire on laptops/desktops. Improved boot times as well.
On a server I want consistency and rock solid reporting and performance. If an aspect fails, I don't want to see it bind up other parts of the system (if it can be helped. A KP is a KP after all).
