Hi,
> > The consensus on wether scripts are generated at build or install time
> > isn't very clear. Does "workstation side" mean the install time generation?
We had some discussion on that on the list, too. I think the argument
"adding support for a new init system and/or fixing a bug in the
generation script must not require a rebuild of all packages" was
quite convincing.
If we generate them at package installation time, maintainers can put
a "update-init-scripts --force foobar" into their postinst when
upgrading from a 'bad' version.
> > Regarding the features that should be supported, while I agree that
> > "restart" can easily be done by stop+start, reload should be supported
> > wherever possible. Be it by specifying a signal (which probably needs a
I in general agree with you on that one.
However, to get the project going I'd start with a subset of the
features; so I'd go with supporting restart=start+stop and
reload=sighup or start+stop only for the first version.
Once we have converted some packages over we'll probably have a
clearer vision on the requirements.
Things like 'rndc' for bind or 'apache2ctl graceful' would of course
be important to support at some point. But it's (to me) not yet clear
whether we need to allow full shell snippets for the restart/reload
actions, of if maybe a single command is sufficient.
SysV-style shell init suffers from one mayor issue: it expects all
services to background and take care of their own respawning.
Newer init systems are designed around service monitoring, so they can
take appropriate measures when a services fails (and restart it, maybe
even restart dependent services).
This is the main point we need to work on, getting these two paradigms
into the same meta-init system.
>From the BoF docs, the plan is currently to support only the
non-forking (i.e. foreground) approach. Some apps that don't work this
way that I'm aware of are apache and mysql.
(Mysql can be run in foreground though. There is just some odd
shell-wrapper around it that tries to make sure it restarts on a
crash... this isn't really needed with a better init system)
> It is not completely clear yet. Consensus was that the generated files
> are deleted when the daemon is removed (even when not purged). Other
This should be left to the package maintainers decision IMHO. I'd go
with on-removal by default, but there could be some services which
need to keep their data files around until purge maybe?
> cases have to be discussed. Especially the case of a daemon upgrading to
> a new version that does not use metainit any more, when the user has
> modified the metainit file :-)
In such a case, the maintainer should trigger a "update-init-scripts
--remove package" IMHO.
Two more things I'm missing from the BoF 'features' list:
- restart flag. Is the services meant to be respawned automatically.
Many init scripts are single-shot, such as hwclock.
- is-installed, is-enabled check or something similar. Many packages
currently use files in /etc/default where you can disable/enable the
service; and pretty much every init script checks if the executable
file is still available (because configfiles might remain; with
respawning init systems this can be very annoying...).
best regards,
Erich Schubert
--
erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To understand recursion you first need to understand recursion. //\
Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_
eine Stunde wie eine Heimat aus. --- Herrmann Hesse
_______________________________________________
initscripts-ng-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
