----- Original Message -----
> Hi,
>
> > > a common init.d script for differents daemons?
> >
> > Yes, I would strongly discourage it from a packager
> > perspective, it would
> > make it harder to do split packages which are a great feature
>
> Sven's script can be configured by setting
> AVAIL_MODULES="scheduler poller reactionner broker arbiter"
>
> Why not let the script ask $0 and set this list accordingly?
> For example, a poller package could install the base script
> "init-shinken"
> as /etc/init.d/shinken-poller and inside there is:
>
> # maybe preset the list
> AVAIL_MODULES=""
> # add the correct submodule for the current init-script
> AVAIL_MODULES="$AVAIL_MODULES ${0##*/shinken-}"
>
>
> Gerhard
Per daemon scripts are also easier to integrate with configuration
management systems were you want to restart a specific daemon when
a configuration file is modified. Most of them will only take a
service name which is then used to call the appropriate initscript
in /etc/init.d
Shipping a symlink as an initscript is doable in a deb package but
would prevent me from using all the automated stuff and write my
own maintainer scripts basically making my life harder :)
The LSB specify that an initscript should accept a single argument
[stop|start|etc..] which would work with AVAIL_MODULES but then it
makes it hard to query the status of a single daemon.
http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
What's the motivation behind using a single initscript? If it's to
reduce code duplication then a good solution may be a shared shell
functions file in /usr/share/shinken/... and a minimal initscript
per daemon that sources the shared file. It would comply with the LSB
and make the packaging systems and packagers happy I think.
Michael
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 5740
> (20101228) __________
>
> E-Mail wurde gepruft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows
> customers
> to consolidate database storage, standardize their database
> environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC
> database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
