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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
