PostgreSQL and MySQL can both use local sockets to handle communication between the client and the server. An indepth description of sockets can be found here, but basically they are special files that act like network connections. The difference is that instead of being available over the network, it’s only available locally. If you only use local connections, make sure you disable the network connections for increased security.

PostgreSQL’s local socket looks something like this:
srwxrwxrwx 1 postgres postgres 0 Oct 17 16:57 /tmp/.s.PGSQL.5432

And MySQL’s looks like this:
srwxrwxrwx 1 mysql daemon 0 Aug 17 17:57 /var/lib/mysql/mysql.sock

Since the local sockets are actually files, they are susceptible to unlinking. The reason this is noteworthy is that there are often some init functions that clean out /tmp, and that’s not something you want to do after you open a local socket.

On Debian servers, /etc/init.d/bootclean contains the cleanup functions, and these functions are called by mountall.sh and mountnfs.sh. If, for instance, mountnfs.sh is linked in the boot process after PostgreSQL, the local socket could be removed. Restarting PostgreSQL will bring it back, but the next time the server boots it will come up broken.

We found a system with mountnfs.sh linked in as S99, and postgresql linked in as S20. After reviewing the other startup scripts, we moved mountnfs.sh to S19 and now the boot process no longer interfere’s with PostgreSQL’s local sockets.