Issues with the feeds are now resolved

George Notaras — Sun, 28 Mar 2010 06:06:46 +0000

This is just a quick notice that during the last five days there was a problem with the website feeds. The web server returned a 500 Internal Server Error to almost all requests for /feed/ URLs. Also, there was a big increase of the server’s CPU load behind the scenes, which was caused by php-cgi processes. It turned out that a custom plugin (unpublished) I had written for WordPress in the past was the cause of all the trouble, but, before coming to that conclusion, the fact that the problems had started without me doing anything on the blog during the last weeks together with a series of other random observations led me do a thorough examination of the whole server just in case.

So, after spending two days in front of a Linux terminal, I came to the conclusion that the following code had been problematic from the beginning and it was like a time-bomb for which the time had come to cause issues to the web site and the server that hosted it.

function rsse_add_related_posts($PostBody) {
  if (!rsse_verify_feed()) { return $PostBody; }
  if (function_exists('yarpp_related')) {
    $PostBody .= yarpp_related(array('post'),array(),false,false,'rss');
  }
  return $PostBody;
}
 
add_filter('the_content', 'rsse_add_related_posts', 252);

This code used a function of another plugin to attach a ‘related posts‘ section at the end of the full content of each feed entry. As soon as I commented out the above filter and started attaching the related-posts section to the feed content through the YARPP plugin’s administration interface, everything was normal again. No more php-cgi processes timing-out or over-consuming the CPU cycles.

The following graph shows clearly the problematic period:

php-cgi processes consuming the CPU

The httpd error_log included many errors like the following:

[...]
Allowed memory size of 33554432 bytes exhausted (tried to allocate 18893 bytes)
[...]
mod_fcgid: process ... exit(communication error), terminated by calling exit(), return code: 1
[...]
[warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[...]
[warn] mod_fcgid: stderr: PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 4864 bytes)
[...]
Premature end of script headers: index.php
[...]

Note that these errors might appear in several occasions.

In my case, finding that faulty piece of code was a huge relief, I can tell you.

Issues with the feeds are now resolved, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Terms and conditions beyond the scope of this license may be available at www.g-loaded.eu.

Making a directory writable by the webserver

George Notaras — Tue, 09 Dec 2008 13:21:02 +0000

I’ve used the phrase “writable by the webserver” numerous times throughout this blog, without ever bothering to explain in detail what this means. Yesterday, I received an email asking me exactly that, so I decided to finally write a post about it and use it as a reference whenever I use the aforementioned phrase. I’ll use Apache as an example webserver and a filesystem with Unix-like permissions. I’ll also try to keep the article as short as possible.

First of all, the webserver, Apache in our case, is a program running in the background. Apache is originally started by user root. We will call this initial process the “root-process“. The “root-process” launches several child processes which handle the client requests. For security reasons, the child processes are not run by user “root” but as a user with minimal privileges. Usually this user is named apache or www-data etc. To find out how this is called in your system, issue the following command:

$ ps -ef | grep httpd | grep -v grep
root      1926     1  0 Dec03 ?        00:00:55 /usr/sbin/httpd.worker
apache    2608  1926  0 14:31 ?        00:00:06 /usr/sbin/httpd.worker
apache   22192  1926  0 01:05 ?        00:00:02 /usr/sbin/httpd.worker

So, in my case the child processes are run by user “apache“. This could also be determined by the user and group directives inside Apache’s configuration file, /etc/httpd/conf/httpd.conf:

User apache
Group apache

So, in order to make a directory writable by the webserver we have to set the directory’s owner or group to Apache’s owner or group and enable the write permission for it. Usually, we set the directory to belong to the Apache group (apache or www-data or whatever user is used to launch the child processes) and enable the write permission for the group.

chgrp apache /path/to/mydir
chmod g+w /path/to/mydir

In many cases, usually in shared hosting environments, it is not possible to change the ownership of files and directories. In those cases you could just set the write permission for everyone (others):

chmod o+w /path/to/mydir

Which method is more secure depends on how /path/to/mydir is accessed.

If it is accessed through the web server with an HTTP request it does not really matter which of the above methods has been used in order to make /path/to/mydir writable by the web server, because, in any case, the web server will be able to write to /path/to/mydir.

If the directory is accessed by other means, for instance by another local program which is run by an untrusted local user, then, obviously, the first method is more secure.

I guess this explains how to make a directory or file writable by the web server process.

Making a directory writable by the webserver, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Terms and conditions beyond the scope of this license may be available at www.g-loaded.eu.

G-Loaded Journal » Web Applications

Issues with the feeds are now resolved

Related Articles

Making a directory writable by the webserver

Related Articles