On Thu, Feb 21, 2008 at 12:33:33PM -0500, Jameson Rollins wrote: > I think that the current practice of replacing any supervise > directories in the service directory with links to /var/run is > probably the right thing to do. However, this has the adverse > consequence of not being able to maintain non-default permissions on > supervise directories (if, for instance, it is desired to set looser > permissions on service supervise directories so that non-privileged > users may be allowed to check the state of a service). > > If using update-service, any permissions set on the supervise > directories before they are added are removed when update-service > removes the old supervise directories and replaces them with links to > /var/run. When runit then creates the supervise directories in > /var/run, it then does so with default permissions. At this point the > permissions could be manually changed, but if the service is later > removed from system-wide supervision and re-added with update-service, > then the permissions will again be reset.
Yes, you're right, thanks. We definitely should change that. > It occurs to me that the permission on the supervise directories > *could* be set by the run scripts themselves. However, this kind of > futzing by a service on it's own supervision seems a little > undesirable to me. Okay. > I'm not sure what the proper way to handle this is, though. The only > thing I can think of at the moment is a runit configuration directive > that can be placed in the service directory that tell the supervising > daemon the permissions to use when creating the supervise directory if > it's not there; something like: > > $ cat <servicedir>/<service>/supervise_perms > 0755 > $ > > I would be happy to have a discussion on the issue. I would like to > figure out a solution, since it is occasionally desirable to make the > supervise directories readable for non-privileged users (we use this > in cereal[0], for instance). Currently update-service --add doesn't touch the ./supervise/ subdirectories if <service-dir>/supervise already exists and is a symlink. So the cereal package could create symlinks pointing to elsewhere in the filesystem before running update-service --add. But maybe update-service should generally place the actual supervise directories not into /var/run/, but /var/lib/runit/supervise/ maybe? Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
