If the issue is Cause 1 from above, then a COLD REBOOT of the Vertica server may help to resolve this.
This is due to the ’s’ bit indicating a UNIX/LINUX file type of ‘socket’. A socket file is not a regular file, it's more like an IP address. A socket file is created by the system when a program attempts to bind to a unix domain socket (by calling a TCP socket Bind function).
This type of network socket is one that is internal to one computer and is used primarily for inter-process communications. The system then associates this special file with the socket file descriptor that the program bound, or more specifically, the "inode" to which that file descriptor refers.
An inode is a data structure that describes objects (such as files or directories) in Unix type filesystems. After its creation, the program that created the socket ‘file’ does not interact with the socket via the filename. Instead, it communicates via the inode that is referenced by the files.
So you cannot create it manually and changing it after it has been created by the system will not achieve anything since you would only be changing the set of names that point at that inode. Which means you can connect to the listening program at a new name or manually created file.
The error in the DB.log; <DATE> <TIME> SP_connect: unable to connect via UNIX socket to /opt/vertica/spread/tmp/4803 (pid=7165): Error: No such file or directory, Shows that the problem is that when attempting to start Vertica, the OS does not allow it to create the 4803 socket file since the run-time data for a previous running session has locked this and has not been cleared. The /var/run directory is where run-time variable data is located.
This should be cleared out at each boot of the system. So the quickest way to clear this would be to reboot the OS on which the Vertica node is running.