| Summary: | New USE flag 'daemontools' as an alternative to init.d | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hallgrimur Gunnarsson (RETIRED) <hhg> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | enhancement | CC: | bangert, chutz+bugs.gentoo.org, gentoobugs, hhg, jeremyw-gentoo-bugzilla1, mark, mike, radek, sascha-gentoo-bugzilla, seemant |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 28567, 28631, 28938, 28940, 28941, 28943, 28945 | ||
| Attachments: |
a-svscan-service
Example of init service my local config for damontools |
||
|
Description
Hallgrimur Gunnarsson (RETIRED)
2003-09-09 14:10:47 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 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. 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 :) 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.
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.
Using numbered services would mean moving away from the dependency-based service loading that I so much like :( 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 :) *** Bug 11230 has been marked as a duplicate of this bug. *** 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. 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. My mistake! There are already packages for the man pages, djbdns-man, daemontools-man. 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. 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. 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. 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. Ok, file bugs for the packages you want it added. Okay, I submitted patches for sshd (#28567), more will follow soon. Can you please change the status here to resolved fixed? excellent :) Well, I guess I cannot just close this. Its up to the individual maintainers to add the scripts or not. 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. Created attachment 17784 [details]
Example of init service
This is an example of the init script I created for syslog-ng to use
daemontools.
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. We have to make sure we don't forget to put /var/daemontools in CONFIG_PROTECT by default 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. 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 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. 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 As for /var/daemontools to /var/service - if it is non crusial during upgrade, I do not have an issue. 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.
any news on that? what's the status of this? seems to be dead? 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 =) 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)... 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 ... dont think there's anything left to be done here |