Some file system permission issues have cropped up. It have a couple of
solutions, but would like additional input.
Unix(7) says that unlink(3) or remove(3) must be called on the file
system object created after the address is bound
(/var/run/pcp/pmcd.socket in our case) in order to remove it after the
socket is closed. Actually, the unlink/remove can happen at any time
after binding and the object will then be removed when the socket is
closed (the link count becomes zero). Indeed, experimentation shows that
failing to call remove/unlink on the object results in EADDRINUSE the
next time pmcd tries to bind to this address.
The problem is one of euid and file system permissions when running as a
daemon, as installed. /var/run/pcp is 'drwxr-xr-x. 2 root root' which is
fine when opening the socket, as the daemon is running as root. However
at shutdown time, it is running as pcp and, so, the remove/unlink fails
with EACCESS.
I have 2 solutions and would like some help in choosing or perhaps there
is another solution:
1) unlink/remove the object immediately after binding while we are still
root. In this case, according to remove(3) (which calls unlink(3) in
this case) and Unix(7), the object's name is removed from the directory
listing, but the object continues to exist and the socket remains
available until it is closed. The effect is that the object is no longer
visible in /var/run/pcp (e.g. can't see it with ls) but continues to
exist and remains usable until the socket is closed. Experimentation
confirms that this is the case.
2) Rework the permissions of /var/run/pcp so that they are 'drwxrwxr-x.
2 root pcp'. In this case, the object is visible in var/run/pcp and can
be successfully removed at shutdown time.
I'm leaning toward option 1) as it makes no assumptions about the file
system permissions or about running in daemon mode (as installed or
otherwise). Does anyone have a preference or, perhaps, a better solution?
Thanks,
Dave
|