Efficiency vs. Inefficiency, in a no-holds barred fight.
There are a lot of posts around telling you how to update mysql root password. "Simple!," they cry, "just start mysqld_safe, and use mysqladmin …" But wait, what's that? You don't HAVE mysqld_safe? Well the chances are, you've got one of these new fangled systemd systems, where everything is ass backwards.
Then you went and tried to run mysqld as root didn't you? That didn't work either. Read on …
I have a small VPS server which hosts a couple of low traffic websites. I've been battling it for a couple of years, trying to reduce the memory consumption. The VPS has 0.5Gb RAM, and the same sized swap file. Sure, I could upgrade the VPS, but sometimes this geeky battling stuff is half the fun!
I've been using the two obvious Mysql tuning scripts and altering the configuration gradually over the last year or so. If you've ever looked at any of this yourselves you'll know them: mysqltuner.pl and tuning-primer.sh
So the problem was this. I'd start up Mysql and it would eat up all the memory, start swapping, and eventually invoke oom_killer. The first change I made was to disable innodb. I didn't need it on this server, and immediately memory usage of MySQL dropped to about half. Now it would start up fine, and run for a week or two, but eventually it would crash out. It was using about 300Mb of the available 512Mb RAM, but would eventually use up all the swap as well. I set up monit to watch it and restart it when that happened, but that wasn't a great solution, so I started chipping away at the my.cnf file, to reduce memory footprint.
The default log viewer application that comes with Ubuntu, Mint etc, is called gnome-system-log. Sometimes it tries to display logs which don't exist and comes up with an error, eg: "Error when getting information for file '/var/log/mail.log': No such file or directory". However there is no obvious way to clear this message and stop it … Read more
It was a routine update, you've done it a thousand times. You select the plugins that need updating, hit update, and browse away while its all happening. Big mistake. You have to stay on the WordPress page for the update to finish. Now when you go to visit any page on your site, you see … Read more
I've been happily running Logwatch on several servers with the default 'yesterday' date range for several years. However I needed to run it for a client with a larger date range to check out a problem. But the options available for logwatch are only 'today', 'yesterday' and 'all'. Or so it told me. And even worse, the 'yesterday' option takes the date from the previous day, and pulls out all the info on that date. So if you run your logwatch report at 4pm, you're missing out on 16 hours worth of data! But it turns out logwatch is smarter than that …