I believe the problem here is that maradns does not detach itself like a
proper daemon should. The evidence is pretty much due to logging of the
HUP signal which unsurprisingly in the maradns code is linked to
receiving a HUP signal. I suppose also when you upgrade at some level
when you upgrade dpkg forks off a process that runs invoke.rc-d as
determined in the postinst script and when the child process (which is
an ancestor of the maradns process in that case) finishes the maradns
receives a a SIGHUP.
So in /etc/init.d/maradns what we need start-stop-daemon to do is
* create a pid file (as it does now)
* go into the background using the --background argument (which it does
not curently do)
* Use logger to connect stderr/stdout to syslog (which it does at the
moment)
All this seems to be too much to do in one shell script. The current
script is a long way from the Debian standard and is complex. And about
half the maradns bugs relate in some way to the init scripts.
I am not willing to take this upstream until we are on maradns 2.x. I am
not willing explore maradns 2.x seriously until we are handling the
multiple processes adequately. Also Sam has a right to expect a tried
and tested proposal rather than a Debian integration problem. Since
maradns 2.x introduces more processes it would make the issue worse. In
any case I think a may have a workable idea that does not require taking
the issue upstream.
1.) Have two daemon processes a maradns and a logger. (Or xN if multiple
servers are configured.)
2.) The init scripts will be resynced with the Debian standard as much
as possible.
3.) The maradns script will depend on (or have a higher number) than the
logger init script.
4.) The logger script will mkfifo a named pipe before it starts the
logger process and the pipe will be the stdin of the logger process.
The logger script's stop action will destroy the named pipe.
5.) The maradns will have the named pipe as its stdout and stderr.
Probably similar techniques will be required for teh zone server and
deadwood. I propose putting those into separate packages with one source.
Given the radical nature of this proposal I propose putting it into
experimental rather than unstable. If you intend to use this please let
me know. I would also like to look into dependency based init scripts as
I think that would help some of the other issues.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
