On Thu, Feb 21, 2008 at 10:23:06PM +0000, Gerrit Pape wrote: > 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.
Ah. I hadn't fully appreciated that. We can definitely do that with cereal for now. The thing that's a little funny, though, is that cereal creates it's session service directories in /var already (/var/lib/cereal/sessions), so the links would just be from one location in /var to a different one. This seems slightly redundant to me, but obviously still doable. Maybe update-service could just check to see if the supervise directory ultimately resides in /var to determine whether or not to replace it, ie: readlink -f "$svdir"/supervise | grep -q '^/var' This still requires the system to be supervised to pick an appropriate place to put it's supervise directories ahead of time. This isn't too bad, but part of what's nice about update-service is that you can be agnostic about this kind of stuff (ie. where the run and log and supervise directories are ultimately supposed to go) and update-service can put things in the right place for you. Another solution would be to have update-service read the permissions of the supervise directory that's there before it deletes it, and then create the new supervise directory itself in the appropriate place with the correct permissions, and then create the link in the service dir. > But maybe update-service should generally place the actual supervise > directories not into /var/run/, but /var/lib/runit/supervise/ maybe? After reading the Debian FHS for /var [0], I think that this is probably the right thing to do, and maybe actually a more appropriate place that /var/run. From the description of /var/lib: "This hierarchy holds state information pertaining to an application or the system" This is a pretty good description of what's actually in the runit supervise directories. Doing this doesn't solve all the issues in about supervise directory creation mentioned above, but it definitely gets around the issue of /var/run being purged on reboot. jamie. [0] http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#THEVARHIERARCHY
signature.asc
Description: Digital signature
