Re: Daemontools wrapper packages
Hi,
> 0. don't DEPEND on daemontools, just let <package> use it if available.
No no, I think you have not understand what I am going to do. I don't want to
package a NEW service running under daemontools. I want to package wrappers
for EXISTING services (apache, proftpd, sshd, ...). So you can install
apache.deb to let apache run in the normal way (init.d) and you can
OPTIONALLY install apache-sv.deb to setup the installed apache for
daemontools. This "wrapper package" will replace the init.d script so you can
control apache in the common way (the script uses svc to control the
supervised apache). If you no longer want to use apache under daemontools you
can simply remove/purge the apache-sv.deb package and everything is like it
was before. That's my goal.
That it is no problem to package a native service for daemontools is clear.
> 3. /etc/init.d/daemontools package should start before any init.d scripts
> using it and it should put down file in all directories under
> /var/lib/svscan/
Sorry, I don't agree with this. Daemontools is not intended to be used in
that way.
> 4. If init.d scripts detects daemontools it switches to DT mode:
Are you going to tell me, that the maintainers of apache, proftpd, ssh and
all the other packages should change their init.d scripts to check for
daemontools?
> a) start will do ( cd /var/lib/svscan; rm <package>/down; svc -u
> <package> ) b) restart will do ( cd /var/lib/svscan; svc -t <package> )
> c) stop will do ( cd /var/lib/svscan; touch <package>/down; svc -td
> <package>; )
Why are you deleting and touching the down file if you stop and start the
service? And why are you doing -td? The down command already sent a TERM
signal to the supervised process.
> 5. make daemontools debian package should provide some support scripts
> which will simplify changes listed in (4.)
Let me explain, how I am doing it now (Lintian clean way):
1. I have written some shell scripts which I am going to package as svtools
in the next time. This package includes some scripts for easy access to the
multilog logfiles (mltail, mlcat, mltac, mlhead) and some helper scripts for
supervise:
svdir: To automatically determine the directory, where svscan is looking for
services.
svinfo: To read some infos about a supervised process from the status file.
(PID of the process, When it was started, If it is marked as
down...).
svsetup: To easily setup a new supervised service (Creates run template,
sets up multilogging, creating users, ...)
svinitd: An init.d frontend. Translates commands like start, stop, restart,
to svc commands.
svinitd-create: Outputs an init.d wrapper template script.
2. Every init.d-wrapper package (i.e. apache-sv) depends on this svtools
package. When installing such a package, the original service is terminated,
the original init.d script is diverted and replaced by a script that is
created at installation time with the help of svinitd-create (The created
script does basically only call svinitd). svsetup is used to install the
daemontools files and to create the necessary users.
3. svinitd checks if the environment variable INIT_VERSION is set. If yes,
the init.d-script is called from the init process and so initd exits
immediately. In that way the init.d-scripts are only doing something if
called from the user and not on system startup/shutdown (daemontools is
handling the startup and shutdown of its supervised services on system
startup/shutdown)
4. When removing a sv-package, the supervise-files are removed, the init.d
script is removed and replaced with the original init.d script and then the
original service is started.
Well, this is already working fine. Does anyone see a policy violation in the
way I am doing it? (Maybe because the init.d-wrapper-script is generated at
installation time and its not a conffile). You can find some beta packages
here:
svtools:
ftp://ftp.codepark.org/debian/dists/woody/main/source/misc/
proftpd-sv, slapd-sv, ssh-sv, telnetd-sv:
ftp://ftp.codepark.org/debian/dists/woody/main/source/net/
--
Bye
K
Reply to: