Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 28294 - New USE flag 'daemontools' as an alternative to init.d
Summary: New USE flag 'daemontools' as an alternative to init.d
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 11230 (view as bug list)
Depends on:
Blocks: 28567 28631 28938 28940 28941 28943 28945
  Show dependency tree
 
Reported: 2003-09-09 14:10 UTC by Hallgrimur Gunnarsson (RETIRED)
Modified: 2006-11-05 01:00 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
a-svscan-service (a-svscan-service,560 bytes, text/plain)
2003-09-09 16:21 UTC, Georgi Georgiev
Details
Example of init service (syslog-ng-new,1.90 KB, text/plain)
2003-09-15 17:34 UTC, Mark Francis
Details
my local config for damontools (damontools-configs.tgz,9.36 KB, application/x-gzip-compressed)
2003-11-14 21:43 UTC, Junji Shiokawa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-09 14:10:47 UTC
Hello friends !

I'd like to propose a new USE flag.

On my systems I've added a 'daemontools' USE flag
as an alternative to the current init.d for
service management. To be a true metadistribution,
it doesn't seem fair to let init.d have a monopoly
on service management.

For those who haven't heard of it before, daemontools
is a process supervisor that can manage services.
For more information see http://cr.yp.to/daemontools.html

Integration of this functionality into ebuilds is in
most cases very trivial. Packages that wish to
provide daemontools USE flag support provide
a 'run' file, that is copied to a service directory,
/etc/daemontools/servicename, or something in that
direction.  We could even have some automated facility
for preparing service directories.

People can then choose what to use for running a particular
service, /etc/init.d or linking the service directory into
/service if the package provides daemontools support.

-- hhg


Reproducible: Always
Steps to Reproduce:
Comment 1 Mike Williams 2003-09-09 14:30:01 UTC
My only problem with this idea is simply that daemontools will need quite a bit of 
usuability patching. Dan's work has always been technically great, but not exactly the 
easiest or most obvious to use. 
 
For example: 
It has no man page 
The only help available is by giving it an unknown/invalid option, and that's not exactly 
informative. 
Service status? 
Any I'm sure there are many more 
Comment 2 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-09 14:42:07 UTC
Yes, valid points. It lacks documentation, but the daemontools
package is already in the portage tree, and there are packages
using it, qmail for example. So the lack of documentation is
still an issue even if the USE flag isn't added.

The webpage http://cr.yp.to/daemontools.html is quite comprehensive
though, for example the svc options http://cr.yp.to/daemontools/svc.html,
to get the service status, svstat directories.

There are also scripts to ease the use of daemontools, such as
supervise-scripts, which is in portage.

Anyways, I'd be more than happy to write/collect together man pages
for the daemontools commands. That should fix the easy to use
factor.
Comment 3 Mike Williams 2003-09-09 16:07:01 UTC
I'm already a djbdns advocate, and messing with qmail so am well aware of 
daemontools, but not of supervise-scripts which pretty much fill the usability gaps I 
mentioned! Very cool. 
The service status is so simple, but amazingly useful. 
If I had to pick a fault, it would be wanting for an rc-update/chkconfig style wrapper 
around the, err, wrappers :) 
service [status|add|start|stop|etc] <service> 
service list [<service>] 
 
On another note, I assume the "init" scripts daemontools uses to run services will 
handle the ordering of startups and shutdowns? (i.e. Gentoo' init depend() function) 
 
Moan, moan, moan, questions questions questions :) 
Comment 4 Georgi Georgiev 2003-09-09 16:21:18 UTC
Created attachment 17368 [details]
a-svscan-service

I like the idea of having services started from scripts in /etc/init.d/ even if
I am using daemontools. I therefore use the attached script to do just that,
and I have a file called "down" in each linked directory in /service to prevent
the service from being automatically started. I currently simply link the
script with a new name for every service. A downside of this approach is that
depend, need, use, before, after are not usable.
Comment 5 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-09 16:30:06 UTC
Ah, yes, this is all a matter of taste.
I would rather completely skip using init.d since I've
never really liked it.

About the startup order, I hadn't really given thought to
that.

I suggested earlier to create a /etc/daemontools directory
for the services, which can then be linked to /service.

To solve the ordering issue, we could have a numerical
ordering system, similar to /etc/env.d, i.e.

/etc/daemontools/02ssh
/etc/daemontools/05qmail-send

then at startup we would run something like

for i in /etc/daemontools/* ; do
    ln -s $i /service/$(cat $i/name)
done

This is just an idea, but we can come up with some
mechanism.
Comment 6 Georgi Georgiev 2003-09-09 18:27:58 UTC
Using numbered services would mean moving away from the dependency-based service loading that I so much like :(
Comment 7 SpanKY gentoo-dev 2003-09-09 20:32:43 UTC
i think the request should be to have specific packages add support for daemontool init script rather than trying to replace init.d ...

and that way if something breaks cause they're using daemontools well it's their own fault :)
Comment 8 SpanKY gentoo-dev 2003-09-09 20:55:24 UTC
*** Bug 11230 has been marked as a duplicate of this bug. ***
Comment 9 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-10 06:09:16 UTC
Yap I second that. It's probably the best first step for the time being.
Internet services like sshd, qmail, djbdns, pop daemons, etc, etc,
would mostly be offering daemontools support, so people would continue
running the basic core stuff through init.d.
Comment 10 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-10 08:58:34 UTC
Regarding additional documentation. It seems that Gerrit Pape (
http://smarden.org/pape/) has converted the html documentation to
man pages (http://smarden.org/pape/djb/)

Here's a direct link to the daemontools man pages:

http://smarden.org/pape/djb/manpages/daemontools-0.76-man.tar.gz

He did the same for djbdns and ucspi-tcp:

http://smarden.org/pape/djb/manpages/djbdns-1.05-man.tar.gz
http://smarden.org/pape/djb/manpages/ucspi-tcp-0.88-man.tar.gz

I think we should include them in the ebuilds as a default.
Comment 11 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-10 09:11:50 UTC
My mistake! There are already packages for the man pages,
djbdns-man, daemontools-man.

Comment 12 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-11 01:59:59 UTC
I might be wrong here, but last time I checked, daemontools was in the league
of start-stop-daemon, just much more advance.  As somebody mentioned, what
you rather want to do, is use per rc-script support for daemontools.  We
used to do this, but because of the licensing dropped it, as we would not
be allowed to distribute binaries.

If something needs to be changed for better support (I cannot think of anything),
sure, add a bug like this with the issue.  Else add bugs for whatever you want
to have DT and not SSD manage the service.
Comment 13 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-11 02:24:22 UTC
Yes, I agree on using per service support for daemontools, it'd
require some juggling to get it to replace init.d completely,
and I dont really care about that, I only want to run some services.
I wouldn't want to run daemontools through a init.d rc wrapper, that's
not the right way to do it. If you want to wrap the starting and stopping
of services you should rather use the supervise-scripts package, not
modded init.d rc scripts.

The issue is not to use daemontools instead of start-stop-daemon,
but daemontools instead of init.d for manging a particular service
(starting, stopping, restarting, logging and signal delivery).

An init.d script only offers limited support of those capabilities,
the stopping can be quirky (yes, that's start-stop-daemon), logging
is not supported in the way it's done in daemontools and init.d doesnt
really allow you to send signals.

In addition, as I said earlier, qmail and djbdns are already
using daemontools. By adding a USE flag, people can choose
between running qmail/djbdns via an init.d script or with daemontools.
I'm sure some init.d fans find it annoying to have daemontools and
would prefer to run them through init.d, and I could run them
and others with daemontools.

This thread kind of got off topic, all I wanted was a USE
flag. Services supporting that flag would offer a daemontools
run file.
Comment 14 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-11 05:27:25 UTC
Then you are going to dup a lot of work already done (sorda).  If you have
whatever in /etc/init.d/ just start and stop it during startup, then you
do not have the headace of managing the starting order, deps, etc.  You are
still then free to use the rest of daemontools's features as you require.

What is more, if there is really something that could make it easier, I guess
we could talk about it, like say:

DAEMON_MANAGER="start-stop-deamon"
#DAEMON_MANAGER="blah blah blah"

DAEMON_MANAGER_ARGS="-foo -bar"

in /etc/conf.d/rc for an easier way to control what we use to start
and stop the services.
Comment 15 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-11 05:48:51 UTC
There are essentially two issues here at hand.

On one hand I'm talking about creating a daemontools
USE flag which says a package can provide a daemontools
'run' file, which will _always_ be necessary
(init.d or not) if the service is to be supervised
by supervised by daemontools.

On the other hand, you're talking about a configuration
add-on for init.d that'll use daemontools instead of
start-stop-daemon. That's okay, but it's a completely
different issue.

The first step is to create the USE flag which means
a service can be supervised, then you can introduce
the init.d configuration option for using daemontools.

So to sum it up:

- The daemontools USE flag, says a package will provide a run file.
- An add-on for init.d if users want to launch daemontools services
with init.d (can also use supervise-scripts for easy wrappers).
- This will also make it possible for users to select init.d
instead of daemontools for like qmail and djbdns.
Comment 16 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-11 07:02:17 UTC
Ok, file bugs for the packages you want it added.
Comment 17 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-12 18:30:34 UTC
Okay, I submitted patches for sshd (#28567), more will follow
soon. Can you please change the status here to resolved fixed?
Comment 18 SpanKY gentoo-dev 2003-09-12 19:15:11 UTC
excellent :)
Comment 19 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-14 11:44:58 UTC
Well, I guess I cannot just close this.  Its up to the individual maintainers
to add the scripts or not.
Comment 20 Mark Francis 2003-09-15 17:29:05 UTC
I have been researching the use of daemontools in init scripts with considerable success. I have some comments that I would like to share.

1. I modified a number of init scripts to run daemontools supervise for the daemon and, where needed, a logger. The changes do not require daemontools to be installed. A check is made that both daemontools is installed and the daemon does not have a file "noinit" in it's service directory, otherwise the script uses the current method (usually start-stop-daemon).

2. I placed the daemontools service directory for each daemon as a subdirectory of /var/daemontools. I notice that bugs 28567 and 28631 store the service directory in etc. My problem with this is that control and lock files are therefore created in etc which seems to me to be wrong.

3. This method has flexibility in that a user can choose to start each daemon in any of 3 different ways. The existing method (usually start-stop-daemon) in an init script, supervise from an init script, or svscan by creating a link to /var/daemontools/$name at /service/$name. Running supervise from the init script has the advantages of both init dependancy support and daemon monitoring.

4. This method does not actually require a daemontools flag, only the modification to an init script and the creation of a service directory under /var/daemontools for each target daemon.

5.  So far I have modified init scripts and created service directories for cups, fam, fcron, ntpd, portmap, samba, sshd, syslog-ng, and xinetd. I can make my changes available if there is interest in this approach.
Comment 21 Mark Francis 2003-09-15 17:34:33 UTC
Created attachment 17784 [details]
Example of init service

This is an example of the init script I created for syslog-ng to use
daemontools.
Comment 22 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-15 19:47:29 UTC
Thanks for sharing! This is great!

Yes, it might be better to have it in /var/daemontools
than /etc/sshd or /etc/proftpd, etc. I wasn't sure
were to put it.

It's true, we don't really need a use flag. I'm going to 
write a document on using daemontools in gentoo that'll
give instructions to propsective users as well as ebuild
maintainers that wish to provide daemontools support.

I'd really like if you'd share the modified init.d scripts
that you've done so far. We can then work together on
getting the corresponding maintainers to incorporate them.

As soon as I have finished the first draft of the document
(prolly get to it later tonight I'll post a link here to
get your feedback and comments.
Comment 23 Georgi Georgiev 2003-09-15 19:48:59 UTC
We have to make sure we don't forget to put /var/daemontools in CONFIG_PROTECT by default
Comment 24 Mark Francis 2003-09-16 23:48:30 UTC
I have created bugs 28938, 28940, 28941, 28943 and 28945 to add daemontools support to the init script for samba, xinetd, fcron, cupsd and syslog-ng. Feel free to try it and see what you think. I could do more if this approach eventually gets the nod.
Comment 25 Hallgrimur Gunnarsson (RETIRED) gentoo-dev 2003-09-17 01:00:09 UTC
Great work ! I'm starting to go over it now. I wrote a small
guide that sums up the main issues and will server as a FAQ
for gentoo daemontools issues in the future (supposing this goes
through). I expect it to grow as thoughts and comments start
coming in.

http://dev.gentoo.org/~hhg/gentoo-daemontools-1.html
Comment 26 Mark Francis 2003-09-17 15:29:41 UTC
petre.rodan@ravantivirus.com suggests that /var/daemontools should instead be /var/service. This would then be consistant with sys-apps/supervise-scripts. Either works for me.
Comment 27 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-20 11:24:53 UTC
Ok, this should be the 'parent' bug, so lets discuss here.

I do not have much time, so will try to get to this over the weekend.  I would
however accept any good _clean_ patches (for the generic runscript.sh/functions.sh support) =)

Thanks
Comment 28 Martin Schlemmer (RETIRED) gentoo-dev 2003-09-20 11:33:23 UTC
As for /var/daemontools to /var/service - if it is non crusial during upgrade,
I do not have an issue.
Comment 29 Junji Shiokawa 2003-11-14 21:43:50 UTC
Created attachment 20770 [details]
my local config for damontools

my local ebuild for daemontools and other daemons.
I hope these config will help something this project.
Comment 30 Heinrich Wendel (RETIRED) gentoo-dev 2004-04-26 02:50:35 UTC
any news on that?
Comment 31 Heinrich Wendel (RETIRED) gentoo-dev 2004-08-04 08:23:53 UTC
what's the status of this?
Comment 32 Heinrich Wendel (RETIRED) gentoo-dev 2004-09-22 05:00:58 UTC
seems to be dead?
Comment 33 John Nilsson 2005-02-26 09:48:28 UTC
I'm currently playng around with daemontools, I'll have a look at "runit" too.

Some links:

http://thedjbway.org/
http://www.gluelogic.com/code/daemontools/
http://smarden.org/pape/djb/daemontools/noinit.html

my time is limited, but if I end up implementing a solution that could be incorporated intoo gentoo I'll throw together a GLEP and some patches.

In the meantime, checkout those links and see if you can beat me to it =)
Comment 34 Radek Podgorny 2005-07-26 02:21:46 UTC
I've been playing with runit recently and it's just sweet. I hope it gets
supported officially by gentoo some day (as an optional init system)...
Comment 35 Martin Schlemmer (RETIRED) gentoo-dev 2005-08-02 00:29:00 UTC
I have looked at runit a long time ago, and thought that if nothing else, we
could at least integrate runsv from it ... I do not have the time though, so if
anybody does decent patches ...
Comment 36 SpanKY gentoo-dev 2006-11-05 01:00:32 UTC
dont think there's anything left to be done here