The Perils of Serving Websites From RAM – Part 2

Remember that quote about stupidity?

If what you’ve done is stupid, but it works… then it really isn’t all that stupid.

David Letterman

Sins of the past

Yes, that solution worked well at speeding up my site. No, it did not allow me to delete files. If I deleted a file in either location, it would be copied back every few minutes. I noticed this behavior when I was removing some unneeded plugins from this blog. I was trying to find the cache plugin that was loading old pages, seemingly bringing back deleted plugins. It turned out not to be a caching error, but rsync moved the files back to memory. This was really annoying for about 30 mins until I realized what was happening.

Unison

Enter Unison. Unison works similarly to rsync but brings with it some capabilities of an svn or git-like change tracking. So we had to force an update. Unison wants both directories to be the same to start, or it may delete all files, which is not ideal. To combat this, we have two scripts. One that runs a startup and another that runs every 5 mins.

@reboot /path/to/memstart.sh
*/5 * * * * root /path/to/mem.sh

This allows me to rsync a copy of the /var/www folder to RAM, and start apache if it choked because it’s missing root folders.

rsync -r /var/www/ /srv/www/

echo "Modify Ownership srv"
chown -R apache:apache /srv/www

servstat=$(/bin/systemctl status httpd.service)
if [[ $servstat == *"active (running)"* ]];
then 
  echo "Process is running."
else 
  echo "Restarting Apache"
  service httpd restart
fi

Unison then can run without any errors rebuilding its file signatures.

unison -batch -auto /var/www /srv/www

echo "Modify Ownership srv"
chown -R apache:apache /srv/www

You know when you think you have something figured out, and you don’t? That was yesterday. Today we really have it figured out. At least figured out until tomorrow.