Bug#549112: daemontools: supervise stores state in /etc
severity 549112 wishlist thanks Gerrit Pape wrote: > Please close the bug again, or at least make it severity wishlist. I agree with Gerrit's reasoning. Bug now wishlist. Bye, Joost signature.asc Description: Digital signature
Processed: Re: Bug#549112: daemontools: supervise stores state in /etc
Processing commands for cont...@bugs.debian.org: > severity 549112 wishlist Bug #549112 [daemontools] daemontools: supervise stores state in /etc Severity set to 'wishlist' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549112: daemontools: supervise stores state in /etc
On Mon, Oct 05, 2009 at 06:12:57AM -0400, Andrew Schulman wrote: > 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. http://cr.yp.to/daemontools/faq.html http://cr.yp.to/daemontools/faq/create.html#why http://cr.yp.to/daemontools/faq/create.html#install http://cr.yp.to/daemontools/faq/create.html#remove > 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. The symlinks are managed by root, not daemontools, and define which supervised services are available, device-specific. This belongs into /etc/, just as /etc/rc?.d/. > (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 elong in /etc. Sure there is. supervise is not restricted to root, ordinary users can use it too. The change you suggest would break that, for at least two reasons: permissions and name-space. supervise's standard location for its state information is the ./supervise/ directory. If you, as root, put your service directory into /etc/, you can adjust the location for the files in the ./supervise/ directory by creating a symlink. update-service(8) can help you with that. You can also do manually, and point them into a ramdisk for example. > 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. I'm sorry, I don't agree. There're quite some update-* programs that adjust configuration in /etc/. > 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. It makes sense. And you should look again, there are quite some packages in Debian that use symlinks in /etc/. Please close the bug again, or at least make it severity wishlist. I do see no bug here. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#549112: daemontools: supervise stores state in /etc
Processing commands for cont...@bugs.debian.org:
> reopen 549112
Bug #549112 {Done: Gerrit Pape } [daemontools] daemontools:
supervise stores state in /etc
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549112: daemontools: supervise stores state in /etc
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
Bug#549112: daemontools: supervise stores state in /etc
Package: daemontools
Version: 1:0.76-3
Severity: serious
Justification: Policy 9.1.1
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}.
Thanks,
Andrew.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (400, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26 (SMP w/3 CPU cores; PREEMPT)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages daemontools depends on:
ii libc6 2.9-25 GNU C Library: Shared libraries
daemontools recommends no packages.
Versions of packages daemontools suggests:
ii daemontools-run 1:0.76-3 daemontools service supervision
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
