/run? /var/run? Other? Or Why You Need to Update to the Latest PostgreSQL Initscript

The PostgreSQL ebuilds and initscript are now capable of using either /run or /var/run for the default socket directory.

The ebuilds will determine which to use at build time. The logic simply being, “Does /run exist?” If it does, everything is adjusted accordingly. If not, everything is adjusted accordingly. The old initscript is incapable of using /run or any other socket directory. So, if you upgrade to the latest version of the ebuilds and fail to upgrade the initscript, you’re going to have issues if you have a /run directory.

Also, this may cause a hiccup when an application is expecting the default location to be in /var/run/postgresql rather than /run/postgresql. The proper solution is not to rebuild everything — you can if you want, but that’s time consuming — but to specify the directory to look in for the socket. Anywhere you’d specify the host you can actually specify the socket directory. Or, you should be able to if the application did it right.

Something that is more important for those who have /run or /var/run on tmpfs, the initscript now takes care of creating the directory if it’s missing. With proper permissions of course.

The next neat thing is that the initscript respects two settings it previously ignored. Well, it ignored one setting outright, and allowed you to set another in /etc/conf.d/postgresql-${SLOT} only. If you set port or socket_directory in the postgresql.conf, the initscript will now pick it up and use those settings over what’s set in /etc/conf.d/postgresql-${SLOT}.

The growing pains aren’t over just yet. Out of three machines, one machine didn’t like the new initscript. It couldn’t shutdown an existing, running server. The other two did it just fine. Same setups. Nothing fancy. Just inexplicable. It’s easy enough to shutdown the server manually, and cleanly. Issue the following substituting the path for wherever your server’s data directory actually resides.

# kill -SIGTERM $(head -n1 /var/lib/postgresql/9.1/data/postmaster.pid)

If that doesn’t do the trick, you can substitute -SIGTERM with -SIGINT as that will close client connections and rollback the transactions those clients may have been in, as that is the most common cause as to why -SIGTERM wouldn’t work.

Merry Christmas!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>