On 10/23/2014 02:22 PM, Valdis.Kletnieks@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.