Linux: concerns over systemd adoption and Debian's decision to switch [OT]

Thu Oct 23 19:50:21 UTC 2014

On 10/23/2014 02:22 PM, Valdis.Kletnieks at vt.edu wrote:
> On Thu, 23 Oct 2014 13:43:03 -0400, Lamar Owen said:
>
>> Now, I've read the arguments, and I am squarely in the 'do one thing and
>> do it well' camp.  But, let's turn that on its head, shall we? Why oh
>> why do we want every single package to implement its own initscript and
>> possibly do it poorly?
> Umm.. because maybe, just maybe, the package maintainers know more about
> the ugly details of what it takes to start a given package than the init
> system authors know?

Speaking from my own experience, the actually relevant and 
package-specific guts of the typical initscript could be easily replaced 
by a simple text configuration that simply gives:

1.) What to start
2.) When to start it (traditional initscripts work on a linear timeline 
of priority slots; systemd units have more flexibility)
3.) How to start it (command line options)

This should not need to be an executable script.  This is what systemd 
brings to the table (Upstart brought some of this, too).  It allows the 
packager to declare those details that the packager knows about the 
package and eliminates the boilerplate (that is different between 
versions of the same distribution; I for one maintained initscripts 
across multiple versions of multiple distributions, all of which had 
different boilerplate and different syntax).  I should not have needed 
to learn all the different boilerplate, as that was a distraction from 
the real meat of packaging (it could be argued that the presence of 
syntactically arcane boilerplate is a problem in and of itself: as a for 
instance, the nice 'daemon' function most RPM-based distributions supply 
in /etc/init.d/functions works for some initscripts and not for others; 
PostgreSQL is one for which it doesn't work and it's not obvious at 
first glance why it doesn't); I should simply have been able to tell the 
init system in a declarative syntax that I needed to start the program 
'/usr/bin/postmaster' with the command line options for database 
directory and listening port (among some other items).

And that includes 99% of what the various initscripts do (yeah, the 
PostgreSQL script of which I was one author did one thing that in 
hindsight should simply not have been in the initscript at all). Many of 
the 1% exceptions perhaps don't belong in code that is run as root every 
single time that particular daemon needs to start or stop.  The perhaps 
0.5% remaining that absolutely must be run before starting or stopping, 
well, yes, there should be an option in that declarative syntax to say, 
for instance, 'before starting /usr/bin/postmaster, check the version of 
the database and fail if it's older with a message to the log telling 
the admin they need to DUMP/RESTORE the database prior to trying to 
start again' ...... (the systemd syntax does allow this).

I have personally compared the current PostgreSQL systemd unit 
(/usr/lib/systemd/system/postgresql.service on my CentOS 7 system) to 
the old initscript.  I wish it had been that simple years ago; the 
.service file is much cleaner, clearer, and easier to understand; no 
funky shell quote escapes needed.  And it doesn't execute as root, nor 
does it source arcane boilerplate functions, the source of some of which 
will make your eyes bleed.  And to do a customized version you just drop 
your edited copy in /etc/systemd/system/ and you're done, since it won't 
get overwritten when you update packages.

When configuring Cisco IOS, we use a declarative syntax; the systemd 
.service file's syntax is as readable as the typical startup-confg is.  
Imagine if we used the typical bash initscript syntax to bring up 
interfaces and services on our routers.