systemd vice SysV/LSB init systems - what next ?

["Jóhann B. Guðmundsson"]

On 07/20/2011 09:06 AM, Nicolas Mailhot wrote:
> Le Mer 20 juillet 2011 01:12, Jeff Spaleta a écrit :
>> On Tue, Jul 19, 2011 at 1:33 PM, Nicolas Mailhot
>> <nicolas.mailhot at 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 … is a best practice?
> As I said before, I am not particularly fond of that script, it is clearly
> fugly and I would not have written it this way (to add to your list I loath
> variable port numbers, it makes filtering and selinux hell, people would be
> well advised to use a well-defined port on one of the numerous local ips
> available instead, and map this port to a virtual ip in netfilter if it
> actually needs use outside the box itself).
>
> Nevertheless, there is nothing particularly tomcat specific here, it's mostly
> the kind of generic boilerplate one needs to multi-instanciate a service :
> 1. find free resources not conflicting with another instance (ip, port,
> socket, working directory)
> 2. instanciate them and apply security settings to isolate each instance properly
>
> systemd is advertised as making it possible to get rid of all kinds of generic
> shell boilerplate which is being reinvented right and left in sysv scripts.
> And replace is with clean streamlined reused C implementations. Well, here is
> a (particularly atrocious) example of such boilerplate. Pushing it in
> /usr/sbin tomcat is not cleaning it up, it's just hiding it under the carpet.
> That's exactly the contrary of systemd stated aims.
>
> I know Fedora has not really pushed multi-instanciation before (but there are
> exceptions, see clamav). But our users do need multi-instanciation and
> routinely tweak our init scripts for this reason. They won't appreciate
> systemd pulling the carpet under their feet. If systemd is to be adopted, it
> needs to make it easier to multi-instanciate, not harder.
>
> Not to mention that new constrains like /srv/, selinux, generalized
> firewalling, frequent updates make multi-instanciating a lot harder than it
> used to be so it could really use some init need to replace all the shell goo
> people have to use nowadays
>

If it's not sufficient for administrators to copy a unit file from 
/lib/systemd/system to a new name undir /etc/systemd/system and do the 
necessary changes to run another instance of it and reload the systemd 
daemon then we have templates which allows creation of multiple units 
from a single configuration file.

JBG