reopen 549112 thanks > > supervise stores its run-state information in > > /etc/service/${service}/supervise and > > /etc/service/${service}/log/supervise. According to the FHS, this > > information should go into /var, e.g. in /var/lib/supervise/${service}. > > Hi, the supervise program stores the run-state information whereever you > tell it to store it. If you create a directory /etc/service/foo, and > run 'supervise /etc/service/foo', it'll create > /etc/service/foo/supervise/, true. If you create /var/cache/foo, and a > symlink /etc/service/foo -> /var/cache/foo, and run 'supervise > /etc/service/foo', it'll create /var/cache/foo/supervise/. If you > create /etc/sv/foo, a symlink /etc/sv/foo/supervise -> > /var/lib/supervise/foo, and a symlink /etc/service/foo -> /etc/sv/foo, > and run supervise, it'll use /var/lib/supervise/foo. > > To ease the setup of services with service directories in /etc/sv/ > that'll be linked into /etc/service/, there's the update-service(8) > program that takes care of that. All Debian packages I know that setup > daemontools managed services use the update-service(8) program.
Gerritt, thanks for your answer. Forgive me, but really, this is a mess. There are a several problems. First, the documentation of update-service never explains that the contents of /etc/service must all be symlinks. This is implied by /usr/share/doc/daemontools-run/README.Debian, but not stated or explained. Similarly, # update-service --add /etc/service/vbox-TinyXP/ update-service: fatal: /etc/service/vbox-TinyXP exists, but is not a symbolic link. is confusing since update-service(8) never says that a service directory must be a symbolic link. I've been using daemontools for a few years, have read all of the documentation, and never understood this, so I think it's not clear. But OK, so I'm supposed to put my configuration into, say, /etc/sv/name, then run 'update-service --add /etc/sv/name', and update-service will create a symlink /etc/service/name -> /etc/sv/name. It also creates /etc/sv/name/supervise -> /var/lib/supervise/name. Here again, daemontools is storing its state in /etc, now in two places: (1) /etc/service is a tree of symlinks created and managed by daemontools, for the purpose of keeping track of its services. This is run-state information that belongs in /var. (2) /etc/sv/name/supervise is also created and managed by daemontools, to point to its state information for that service. Again this is run-state information. Instead of writing this data into /etc, supervise should just use the standard location for it: /var/lib/supervise/name. There's no reason that a user would ever need to change that location, or even know about it, so it doesn't belong in /etc. It's internal to daemontools. The basic difference is: /etc belongs to me. /var/lib/daemontools or /var/lib/supervise belongs to daemontools. daemontools (including update- service) should never be writing into /etc. Any information it needs to write to keep track of the installed services, it should put into /var/lib/daemontools or /var/lib/supervise. It seems that daemontools is trying to be flexible, by allowing me to put my service descriptions anywhere, and then using update-service to create symlinks in /etc/service for me. But this doesn't make sense. Why not just require that they all go into /etc/service in the first place, and assume that any directories there describe services? That's the standard approach, used by every other package I can think of. Thanks, Andrew. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org