systemd vice SysV/LSB init systems - what next ?

[Jeff Spaleta]

On Wed, Jul 20, 2011 at 3:29 AM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> I don't think someone would have written all the 'find a free port, create a
> new workdir, etc' logic in the tomcat script if just 'copy and change settings
> in the init file' was scaling for his use. After all, 'copy and change things'
> could have been done with the sysv script too, without writing complex shell
> helpers.

I wouldn't call those complex and I wouldn't say they scale. All it
does is make it possible to replicate the default /usr/share config as
packaged, by automating some copying and some file mangling in a very
fragile way. You walk away from the default config by editting that
server.xml file as a site admin and this approach blows up.

And as a day-to-day writer of shell scripts to get things done, shell
scripts I'd never ever encourage anyone else to rely on or reuse
outside of my tailored environments.. I would have to say that you are
probably making the wrong assumption with regard to motivation and
choice of tools and the amount of time spent thinking about how to
make the multi-instance stuff for tomcat be robust enough to be
generally useful for other people. Just replacing hardcoded port
numbers in the default xml file shows a distinct lack of understanding
how how flexible and thus complex active tomcat6 configurations can
be.  The tomcat6 intscript logic seems to go out of its way to ignore
local admin reconfiguration  in /etc/tomcat6/ in order to enforce the
assumed default settings from /usr/share/tomcat6 to make the
multi-instance magic work as desired.  how is this a good thing?  By
putting more flexibility into the shell based init system in the hands
of packagers we now have a situation where a packager's decision
making to be narrowly clever results in ignoring the inherent
configuration flexibility of the actual daemon being initiated.

And even if you do use the default configs, you can't re-instance with
an arbitrary name. Anything starting with an S or a K gets mangled to
try to account for the runlevel symlink naming.

And furthermore since there's no inheritance of logic from the
original tomcat6 initscript that is copied to create to create the
second instance, if the original gets updated via package manager
action to fix logic bugs(and there are logic bugs I assure you) then
your second instance does not inherent the changes. How is this a good
thing?

The tomcat6 intscript multi-instance support is a quick undocumented
and unique hack,  nothing more.  Just look at how it mangles the
executable basename to try to be clever and figure out which file in
sysconfig to use for settings.  Clearly the goal was to try to make it
possible to "just copy and rename" the tomcat6 initscript without the
admin needing to edit anything in the initscript itself and have it
work with a random new named initscript. And you know what that would
be perfectly fine as a site specific hack that an admin cooked up
tailored to their environment.  Similar logic could be run as a
pre-exec script in a systemd unit file if an admin really wanted to do
it. But I certainly would not choose to ship it enabled by default
with its current..problems.  It doesn't actually work in environments
where the local admin has actually tailored their tomcat6 configs (the
real configs in /etc/tomcat6 not the distro specific sysconfig junk).

Whereas the templating features of systemd unit files are documented
and are standardized for _all_ services to make use of and allow for
inheritance from default unit files and admin overrides of those same
defaults. In fact the systemd templating stuff resolves of the
problems in the initscript hack, the undocumented limitations in the
mangling of the basename.

-jef