A few weeks ago I mentioned the “powerful logging features” of CQRLOG. Such features don’t come without a cost. Or, in this case, a “processing” cost. And by processing cost, I mean the type usually tied to using a traditional database. SQL databases aren’t exactly known for their low overhead, which is why CQRLOG was not a good candidate to run on a Raspberry Pi.
My Intel i7 2.7gHz processor with 8 gigabytes of RAM, however, is a different story.
In other words, chances are I’d never notice I was running a SQL server in the background. Be that as it may, I still don’t want services I’m not (currently) using churning away in the background consuming CPU time that could be used elsewhere. Not only is it a good information security practice to disable unused services, I just flat-out don’t want it running if it’s not being used.
I installed CQRLOG directly from the terminal and since I didn’t already have MySQL installed, it was installed as a dependency. Not surprisingly, the installer thought it was being helpful and created a daemon to make sure MySQL was always running in the background. I don’t want, or need, a database daemon running all the time in the background — which leads me to: how do I rectify this problem?
My primary concern is that MySQL is running since CQRLOG depends on it, but it only needs to run when CQRLOG requires it. I begin considering writing a script to handle starting the MySQL process before CQRLOG starts and stopping it when I quit CQRLOG. But before I go off inventing the wheel, I wanted to see what would happen if I tried to execute CQRLOG when MySQL wasn’t currently running.
So I stopped MySQL:
aaron@compy486 ~ $ ps aux | grep mysql mysql 1693 0.0 0.5 484340 43260 ? Ssl 07:56 0:22 /usr/sbin/mysqld aaron 4731 0.0 0.0 9456 944 pts/0 S+ 15:02 0:00 grep --colour=auto mysql aaron@compy486 ~ $ sudo service mysql stop [sudo] password for aaron: mysql stop/waiting aaron@compy486 ~ $ ps aux | grep mysql aaron 4742 0.0 0.0 9452 944 pts/0 S+ 15:02 0:00 grep --colour=auto mysql aaron@compy486 ~ $
…and started CQRLOG:
aaron@compy486 ~ $ ps aux | grep mysql aaron 4750 0.4 0.4 515280 40376 ? Sl 15:02 0:00 /usr/sbin/mysqld --defaults-file=/home/aaron/.config/cqrlog/database/my.cnf --default-storage-engine=MyISAM --datadir=/home/aaron/.config/cqrlog/database/ --socket=/home/aaron/.config/cqrlog/database/sock --skip-grant-tables --port=64000 --key_buffer_size=32M --key_buffer_size=4096K aaron 4777 0.0 0.0 9452 944 pts/0 S+ 15:02 0:00 grep --colour=auto mysql aaron@compy486 ~ $
Surprisingly CQRLOG started MySQL for me! Honestly, I fully expected it to complain about the service not running and I’d have to manually start it. But it handled starting the service for me and I saw no such complaints from the program that it even expected to encounter MySQL already running.
But wait, there’s more!
After quitting CQRLOG, I checked again for any running MySQL services:
aaron@compy486 ~ $ ps aux | grep mysql aaron 6807 0.0 0.0 9452 944 pts/0 S+ 22:07 0:00 grep --colour=auto mysql aaron@compy486 ~ $
Nothing. Not only did CQRLOG seamlessly start the service, but it stopped it when it was no longer needed. That, is quality software engineering. So then that simply leaves us with disabling MySQL from starting when you boot your computer and we’ve pretty much cleaned up this annoyance:
aaron@compy486 ~ $ sudo update-rc.d -f mysql remove [sudo] password for aaron: Removing any system startup links for /etc/init.d/mysql ... aaron@compy486 ~ $
That should prevent MySQL from rearing its proverbial ugly head before being called for. Now if you’ll excuse me, there are more problems I need to create so that I can find something to blog about later…