> Putting that aside for a moment, let's pretend we had a stream socket > in this application instead of a datagram one. I think the right > thing to do at that point would be to add a killpeer() syscall, which > sends a signal to the other process associated with a file > descriptor.
With what permissions checking? If the answer is "same as kill(2)", then you may find it crippled unless daemons run as root, which of course is undesirable. If the answer is "none", then suddenly processes using vanilla AF_LOCAL sockets can get signals from peers that formerly couldn't send them signals, thus creating DoS potential against system processes. I'm not sure what other options exist. Perhaps it could work only if the other side has agreed to receive signals, with a distinctive error if not? (Trying to send signal 0 could probe for this.) Another thought: what if there is other than exactly one process on the other end? Even for SOCK_STREAM, this is possible; multiple processes can have file descriptors referring to a single open file table entry, by means such as fork() or SCM_RIGHTS messages. There may even be no such process, if the peer socket has been closed, or if all references to it are sitting in SCM_RIGHTS buffers in other sockets. (Process X has fd, sends it as SCM_RIGHTS to process Y, but X closes the fd before Y receives the message - who is "the peer process"? What if there are multiple Ys who have access to the socket and could receive the SCM_RIGHTS-bearing message?) > This is reasonably general -- it would be useful for ptys and pipes > as well, I think. I think it would be a very useful tool for cleanup > of potentially misbehaving peers in many local-IPC client/server > applications. I'm concerned about possible abuses of the capability. I don't think signals are an appropriate response to "misbehaving peers"; a more appropriate response is generally to close the communications channel to the misbehaving peer. Even in the case that brought this up, I would say the right answer is not to provide a way to kill off the process, but rather redesign the communications mechanisms so there is no need to kill off the process. While I don't know fuse beyond what manu@ said on Saturday, it seems to me that the right answer is to provide something perfused can do to ensure that it doesn't matter whether glusterfs sticks around, to break whatever connection exists that's allowing glusterfs's persistence to interfere with the next mount. (Or, possibly, not something perfused needs to do; it's armchair quarterbacking to an extent, but it seems to me that this should be part of the unmount operation.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
