Too many references: Cannot splice)
This exact message was seen as early as 2.9BSD without any use, though grouped together with other socket-related errors. The earliest use of this error code was in the "ARGUS Project" network stack used between 4.3BSD-Reno and NetBSD 5, where ETOOMANYREFS was returned when the system reached the limit of 100 ISO Transport Protocol sockets.
Specifically, the ISO TP protocol module (tp_pcb.c) returned this error code whenever it was requested to attach to a socket, but had reached the maximum number of tp_ref structures held in a fixed-size (100 element) array. (Presumably the second part of the error message refers to the system being unable to splice the socket into the array.)
In the 4.4BSD /usr/share/doc/iso/wisc documentation (errors.nr) it was documented as TP ran out of reference blocks
. (Although other protocol modules such as ARPANET TCP also implemented the same attach operation, they would return ENOBUFS instead.)
UNICOS manual documents the error code as: A connect(2) request or listen(2) request failed because no free TP (transport) reference blocks are available. A timer is set whenever a reference block is freed; the reference may not be reused until the timer expires to ensure connection uniqueness within the system. (The time-out period depends on the communication protocol.) This error may be caused by the maximum number of active connections allowed by the system or by many connections being established and closed in quick succession. In either event, try later at an appropriate time.
Nowadays ETOOMANYREFS has found other generic uses in the Linux kernel, e.g. to be returned when reaching a limit of in-flight file descriptors being sent across a Unix socket.
See also: RFS (Remote File Sharing)
Advertise error)
Should have been called: Advertised RFS resource is busy.
Returned by the RFS server subsystem as a variant of EBUSY, in particular when a shared location would need to be un-advertised (i.e. un-exported and removed from the RFS resource directory
) before continuing.
The SunOS 4.1 manual documents this as: An attempt was made to advertise a resource which has been advertised already, or to stop the RFS while there are resources still advertised, or to force unmount a resource when it is still advertised. This error is RFS specific.
# rfstop
rfstop: resources are still advertised.
# dmesg
rfstop: can't stop with advertised resources.
Srmount error)
Should have been called: is busy.
Returned by the RFS server subsystem as a variant of EBUSY, in particular when trying to stop RFS or un-advertise a resource while clients are still connected to it.
The SunOS 4.1 manual documents this as: An attempt was made to stop RFS while there are resources still mounted by remote machines. This error is RFS specific.
# rfstop
rfstop: remote clients are using local resources.
# dmesg
rfstop: can't stop with clients.
Device busy)
Although not an RFS-specific error, it is mentioned here for completeness as it is also used in the same code. Whereas EADV and ESRMNT had to do with local resources being in use remotely, the EBUSY error would be returned in the opposite situation – when RFS was about to be stopped while a local process was still using remote resources (i.e. the same situation as trying to unmount an in-use filesystem).
Cross mount point (not really error))
Returned by an RFS server when a path lookup for ..
has to leave an RFS mount point (e.g. when accessing /mnt/remotesystem/../localfile
Also named RFS specific error
(Linux), Error 76
(SCO), and EDOTDOT!!!!
(SunOS 4.1). This error code is never seen by user-space processes, so it wasn't meant to have a string name at all.
The SCO UNIX manual documents it as A way for the server to tell the client that a process has transferred back from mount point.
Object is remoteor
Too many levels of remote in path)
Returned by an RFS server when receiving a syscall for operations that are meant to be local only (e.g. advertise a path which is already an RFS mount, or mount a filesystem from an RFS-accessed device node).
While originally an RFS error code, it is generic enough that it finds various other uses, e.g. in SunOS 4.1 it was also used by the NFS subsystem when trying to re-export an NFS mount.
Documented in various ways as:
An attempt was made to remotely mount a file system into a path that already has a remotely mounted component.
This error is RFS specific. It occurs when users try to advertise a resource which is not on the local machine, or try to mount/unmount a device (or pathname) that is on a remote machine.
An attempt was made to NFS-mount a remote file system with a file name that already specifies an NFS-mounted file. (This is an error on some operating systems, but we expect it to work properly on GNU Hurd, making this error code impossible.)
In comparison, the Linux NFS server explicitly supports re-exporting NFS-mounted file systems (e.g. to translate between an NFSv4 server and NFSv3 clients), though many other network mounts cannot be accessed this way.
Multihop attempted)
Returned by an RFS server when trying to access a path which itself belongs to an RFS mount.
The SunOS 4.1 manual documents it as An attempt was made to access remote resources which are not directly accessible. This error is RFS specific
while the SCO UNIX manual says Components of path require hopping to multiple remote machines.
SunOS 4.1 source:
/*
* If the mounted filesystem is an RFS type, return EMULTIHOP,
* since RFS does not allow crossing multiple machines.
*/
if (vfsp->vfs_op == &rfs_vfsops) {
errno = EMULTIHOP;
}
Machine is not on the network)
Returned locally by various RFS syscalls such as advfs() while the RFS kernel daemon is not yet running.
Documented in SunOS 4.1 as: A attempt was made to advertise, unadvertise, mount, or unmount remote resources while the machine has not done the proper startup to connect to the network. This error is Remote File Sharing (RFS) specific.
Link has been severed)
Returned by the RFS client code when trying to send over a dead link
(presumably when some other network-related error was propagated from the underlying STREAMS circuit). Similar in purpose to EIO and ESTALE (NFS).
Documented by SunOS as: The link (virtual circuit) connecting to a remote machine is gone. This error is RFS specific.
Within the SCO UNIX manuals, some syscalls list it as a possible return when fildes is on a remote machine and the link to that machine is no longer active
.
Described in RFS Architectural Overview
(USENIX Summer 1986) as: On the client side the recovery process wakes up any client process that is waiting for a response from the crashed server and marks RFS inodes indicating that the link went down, so that subsequent operations on these inodes will fail. It is important to note that a client process awakened by recovery returns an ENOLINK error to the user indicating the server machine crash.
Communication error on send)
Similar to ENOLINK, but apparently used when a virtual circuit hasn't been established at all.
Documented by SunOS as: An attempt was made to send messages to a remote machine when no virtual circuit could be found. This error is RFS specific.