Hi Steven Haigh! On 2014.08.26 at 09:57:22 +1000, Steven Haigh wrote next: > > - simple and predictable service files > > Like my case of networking randomly failing to start. No debugging or > errors logged, and no way of predicting a failure. Err, where did you find system where systemd initializes network? I think in all current distros something else (like NetworkManager) does it, which is significantly more annoying to debug compared to old network scripts, but systemd has nothing to do with it at all. systemd network initialization is/will be available for containers, and it won't appear in EL7 for host system for a long time - maybe at all. I won't deny that switching to systemd might require some tweaking because it all starts "too fast" and some services might fail to init because they are started before network does, but this is to be expected from parallel boot and is fixed by either enabling "networkmanager wait online" service, by tweaking boot dependencies or by other options, like "x-systemd.automount" in fstab for your nfs shares. > > - ability to wrap a random application into service with just a few lines of config > > Yes and no. When you really start using systemd, you learn quickly how > to create service files - because you end up writing a lot of them > because basic options are missing. If your app doesn't utilise a config Learning new things is expected from SA managing these things. Also, bash scripts for "more options" are still there, only now you can put there few lines of actual, meaningful startup code and let systemd call this small script from service file for certain action. > > - no more extra-complicated init scripts using various hacks and magic > > for non-C applications (if you ever tried to wrap some random python or > > java application into service, you'll know what I'm talking about right > > away) > > By complicated you mean working? I start several python daemons on boot > with initscripts - and it is very simple - almost trivial. Compare to > the guesswork of trying to find out why a service failed to start. Starting is easy, stopping and getting status is hard. Especially with complications like "no pidfile from application", "it forks" or "it's launched under script which automatically restarts it". And especially when a (typical large) service takes many seconds or even minutes to shutdown and you need to *actually* make sure it shutdowns by letting it shutdown gracefully for, say, a minute, then kill it with -9. > > - automatic restart of services > > This is not always desirable. It's an option in service file. > > - thanks to these features (service created with few lines of code, > > automatic restart, some others) - no more need for runit, daemontools or > > supervisord , you can have all the benefits of these systems while having > > only one flat init system (systemd) for both system and your services > > - reliable pid tracking, which even follows the forks - that's something > > not current init system or others like runit are able to do. No more > > hassle with complex pgrep's for applications that didn't leave pidfile > > behind (again, applications that rename or fork themselves and non-C > > applications can be extremely annoying here). But systemd has reliable > > way of knowing all the pids that each service has created without any > > hacks at all - thanks to cgroups support. > > None of which really works out of the box without you writing your own > service file. We have used /var/run for PID files for decades - saying > it isn't reliable is .... ignorance? 3 lines for service file vs complicated pid file searching, what wins? pid /var/run requires LOTS of extra work when you're dealing with "lots of random applications which have to work as services". No one bothers / has time to write and control pidfile from application (including correct tracking of stale files, tracking that stale file doesn't belong to different process and such has to be done in script anyway). Application might not have rights to write pidfile, after all - say, you need to run bunch of applications without root rights - it means you must wrap them into package and package /var/run/myapp with correct privileges, then change config/option of each application to write pidfile to /var/run/myapp instead of /var/run and so on. You might call these small things, but what you eventually end with is a very-very long and complicated mega init script for python services and similar mega script for java services, which uses LOTS of bash code to work around all these problems in init, including stale pidfiles and long shutdown times. And try to change as little config lines on top as possible to accommodate to your needs with new scripts. Welcome to systemd: it's possible to throw out these mega intellectual init scripts and just use these few lines in service file. pid tracking with cgroups is very reliable and no amount of hacks and strange behaviour can confuse it, also doesn't require root privileges to write a pidfile. > > > - ... many more, like various niceties for supporting lightweight > > containers with blazing fast startup, where systemd cares about > > organizing namespaces and initializing network by itself (not sure these > > features are in EL7's systemd, though) > > None of these really matter in enterprise land. When the servers RAID > card takes longer to boot than even the initscripts to run, the benefits > are shown for what they are - trivial. I was talking about containers. For ability to launch many containers with just a few services in each it is somewhat important. Why launch lots of small containers? For scalability, at least; when it comes to a moment when you need more resources for services in certain container, it's very easy to move or redeploy this whole container on different host with more resources. > Oh god no. Systemd replaces many things that should not be replaced. > Plans are afoot to have systemd replace ntpd and the idea to replace the > kernel consoles with userspace systemd foo. Lets also ignore the binary > log formats which kills long time monitoring tools (logwatch etc) and > systemd really is a solution hunting for a problem. Why worry beforeahead? systemd doesn't force you to use just journald - in fact, in EL7 rsyslogd is fully supported and is active. Two logging systems work in chain - old one lets you run "long time monitoring tools" till they are rewritten to use new system, and new ones gives you advanced information for each line of log and complex (intellectual, unlike grep) log search options. > > Systemd would have a much better time if it kept its core goal small and > focussed. The mess that it has evolved into has included blowing out its > scope to just about everything on your system. This is the wrong way to > do things. There is no excuse for violating the basic principles of > system design and administration for 'wooo it boots faster'. Its goal isn't to just "boot faster". They wanted to bring many nice (complicated, but still nice) features from SMF to linux world, while improving them, as possible (no more xml config files, yay!). -- Vladimir