[Info-vax] openvms and xterm

[Dan Cross]

In article <v049b8$gqf3$11 at dont-email.me>, motk  <meh at meh.meh> wrote:
>> but are offended by the non-unix-style non-human-readable configuration
>> files.
>
>[stares in sendmail]

Sendmail.cf was hardly typical of most Unix configuration files,
but surely you already know that.  Indeed, I think one could
make a strong argument that sendmail's design, not to mention
its configuration, wasn't very Unix-y at all.  At this point, I
imagine that Eric would agree.

But a fair counter argument to the "but it's not Unix!" cries is
that Unix lacked a robust configuration language that was
ubiquitous across systems and packages.  That was a bit of a
shame, but perhaps inevitable: some programs had very domain
specific requirements for configuration that would be difficult
to express in a generic configuration language (lookin' at you,
sendmail).  Surely any given universal language would either be
insufficient to express the full generality required for all
use cases, or it would be too baroque for simple, common cases.

Also, Unix provided tools that made it easy to construct DSLs
for this sort of thing, sort of encouraging it.  When it's easy
to create your own config file format and corresponding parser
based on a bespoke grammar with tools like lex and yacc, there's
less incentive to adopt some off-the-shelf, standard config
language.

>> Pay attention to the specific arguments people make rather than just putting
>> them all into one category.
>
>You don't have an argument, you're just justifying your dislike of 
>change. Nothing wrong with disliking change of course but please 
>understand that things like smf and systemd came to exist because they 
>were needed for modern infrastructure. The Old Ways just no longer cut 
>the mustard, and people who do this for a living for vital 
>infrastructure were sick of dealing with them.

You may have a point, but to suggest that anyone who objects to
systemd doesn't "have an argument" or is reactionarily change
averse is going too far.  There are valid arguments against
systemd, in particular.

I'll concede that modern Unix systems (including Linux systems),
that work in terms of services, need a robust service management
subsystem.  Systemd is certainly that.  However, it does not
follow that systemd is actually _good_ as a result.  Simply
being useful is not enough to earn that.  And systemd _does_
have weird edge cases; I wrote a service definition once that
invoked a script; the script set up some environment variables
or something and then ran `exec something`.  Systemd thought
that the service had failed because it intercepted that the
service had exec'ed without fork.  To "fix" it I simply didn't
exec the file program; the result was a useless shell process
hanging around just to keep systemd happy.  Yeah, it works, but
that seems kinda janky.

If one takes a step back and thinks about what such a service
management framework actually has to do, a few things pop out:
managing the processes that implement the service, including
possibly running commands both before the "main" process starts
and possibly after it ends.  It must manage dependencies between
services; arguably it should manage the resources assigned to
services.

So this suggests that it should expose some way to express
inter-service dependencies, presumably with some sort of
human-maintainable representation; it must support some sort
of inter-service scheduling to satisfy those dependencies; and
it must work with the operating system to enforce resource
management constraints.

But what else should it do?  Does it necessarily need to handle
logging, or network interface management, or provide name or
time services?  Probably not.  SMF didn't do all of that (it
did sort of support logging, but not the rest), and that was
fine.

And is it enough?  I would argue not really, and this is really
the issue with the big monolithic approach that something like
systemd takes.  What does it mean for each and every service to
be "up"?  Is systemd able to express that sufficiently richly
in all cases?  How does one express the sorts of probes that
would be used to test, anyway?  I wrote a service a year or two
ago that had to wait for a specific symlink to be available; I
ended up writing a script that tested for it in a loop and used
that as the ExecStartPost part of my service, but bear in mind
that the OS already exposes a way to wait for a file to spring
into existence as part of its eventing framework.  Again, this
felt janky.  What if my criteria was more involved, such as
expecting a certain value from an HTTP server on some port
assigned by the service manager?  Support for multi-process
services is there, in the sense that one can define sort of a
tree of services that are managed as a unit by some parent
service, but it's not super elegant.  And what about
cluster-wide service management?  There's a reason organizations
like Google don't use systemd to manage their services.

The counter that things like NTP can drag in big dependencies
that aren't needed (for something that's arguably table stakes,
like time) feels valid, but that's more of an indictment of the
upstream NTP projects, rather than justification for building
it all into a monolith.

Anyway.  I can get behind the idea that modern service
management is essential for server operation.  But it doesn't
follow that the expression of that concept in systemd is a great
example of how to do it.

	- Dan C.