I was troubleshooting an issue at work the other day regarding some PostgreSQL connections that were not closing. They were left IDLE, never closed, and eventually used up all of the possible connections (which totaled 100) configured in the postgresql.conf configuration file. In the process of troubleshooting I noticed a bunch of Postgres log entries that I was unable to immediately pin down to what was causing the entries. Below I describe the view of the idle Postgres connections, the PostgreSQL log entries that were unfamiliar, and the cause of both.
If you have the resources (CPU + RAM) available on your server then its can be a great troubleshooting tool if you enable MySQL logging which includes server messages, SQL query logs, and slow query logs. If you do not have the resources I would suggest only enable minimal logging such as only server messages and the slow query log since enabling all queries to be written to a file can become expensive rather quickly. Below I discuss enabling three different types of MySQL logging, adding a MySQL configuration file to logrotate, and configuring root to run mysqladmin commands without having to type the password out each time.
Yesterday a colleague at my company was doing some testing with a potential partner and they needed to open a TCP port on one of our development servers so an application could bind to that port. At first I wasn’t sure how I should do this since the port didn’t need to do anything but listen for incoming connections and the remote application would simply connect to that port. To get something up immediately for them I simply had our web server listen on the requested port which worked however I did not want the web server running on this port for long so I needed to come up with another solution to simply open the port, listen for connections, and possibly log those connections so we could troubleshoot if necessary. I ended up finding an application called tcpsnoop which I explain how to compile and use below.
I needed to create a bash shell script tonight that called another shell script with options that then would load a Ruby environment and execute certain commands within a Ruby project. I ran into numerous issues but most were silly things such as typos or other minor issues caused by myself. The one issue I had a little trouble figuring out because of the file that was causing the error related to cron not being able to run “/usr/bin/env: ruby”. My bash script worked perfectly from the Linux CLI shell however when attempting to run it I would always get the same error. Below I list details about the error, where I finally located what the error was, and how to resolve the error.
The btmp log keeps track of failed login attempts. I have seen on a default linux setup with logrotate configured where the btmp log is left out of rotation and eventually grows out of hand. So first you want to make sure that the btmp log is rotated using logrotate with the below information.
To rotate the btmp log add the below to the logrotate.conf file located in the /etc directory.