On Wed, Jul 20, 2011 at 3:29 AM, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
