On Tue, Jul 19, 2011 at 1:33 PM, Nicolas Mailhot <nicolas.mail...@laposte.net> wrote: > All this code is here just to instanciate the service and do the related > housekeeping. It does not belong in a separate script any more or less > than the rest of the sysv stuff. That example just shows the sysv setup > was flexible enough to handle complex multi-instanciated setups and > systemd so far isn't
It is your opinion that having init scripts potentially create directories such as /usr/share/tomcat6 as part of boot up and service initialization is a best practice? And initscripts should prefer to edit files in /usr/share instead of editting files /var/ ? because that is some of what the makeHomeDir() function in the tomcat6 initscript does. Is that really something we want to encourage to see being done as part of initscripts? Really? I can't believe that. In fact I'm sort of grossed out by what that tomcat6 initscript potentially does based on conditional logic. Sure creating directories in tmp or var on boot up I can see..but creating and edtting directories in /usr/share? And why isn't it making use of information in /etc/tomcat6 but instead is popularting from /usr/share/tomcat when recreating missing elements? I simply don't understand how this is a good thing. This isn't flexibility to serve a good purpose...this is abuse of a flexible tool to hide system _brokenness_ from an administrator. There's even some clearly deprecated logic in there which try to identify boot time runs of the init versus manual runs with the completely unused ISBOOT, but since ISBOOT is set but unused I can only guess as to what was intended in the past. there's even special casing for Mandriva specifically in that init...awesome. And I'll reiterate with a little more strength. I've read the wrapper script in F15 that gets dumped to /usr/sbin/tomcat6. I see absolutely no reason why the necessary clever random free port locator logic which allows upto 3. additional connectors could not be placed into the distro specific wrapper in /usr/bin/ and run conditionally from systemd based on a cmdline argument that activates the random port locator logic. Why is 3 hardcoded anyways? Maybe because there are by default 3 such instances instances in the default server.xml. What if an admin edits their server.xml under /etc/tomcat6 (which is what I expect an admin to do) tio added a 4th and 5th connector? This initscript logic _fails_. The sed construction itself is also extremely fragile when replacing port numbers and isn't using any sort of variable substitution (like how yum internally does substitution $releasevar for example). And to be quite blunt, the wrapper's argument handling is very very poor. It takes exactly one argument. It could easily be extended to allow for multiple cmdline options and get back the same capability expressed in the initscript port locator logic. I see no reason why the necessary logic to find an unused port and to do the other necessary multi-instance configs needs to be split between init. The logic right now for the random port stuff only seems to fire if /usr/share/$NAME/ is actually missing and needs to be regenerated. What a mess /etc/tomcat6/ exists but not all of the info in there is actually used /etc/sysconfig/tomcat6 exists... why can't that be put in /etc/tomcat6/ ? /usr/share/tomcat6/ exists and is being used as a pattern for multi-instance needs /usr/share/random_name/ will potentially be created based on the contents of /etc/sysconfig/random_name if and only if this init script is copied to a new initscript named random_name I would not hold up the shell logic here as as best practices. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
