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