I use the daemon ‘
memcached‘ to accelerate my blog. But in its default configuration, this daemon runs as user ‘
memcache‘, has only 64M of space configured, and does not have the ‘
-k‘ option set, to pin the virtual memory it is caching into physical RAM. It was a past project of mine, to remedy this, and to that end I put an entry into the file ‘
/etc/security/limits.conf‘ which went like so:
memcache hard memlock unlimited memcache soft memlock unlimited
Thus removing the default limit on how much memory any one user can lock.
But much to by dismay, when launching or restarting, ‘
memcached‘ would leave a characteristic error message in my
syslog, which indicated that it did not have permission to lock – say 128M – of RAM.
The solution which finally worked for me, was also to change the configuration of the service to include the option ‘
-u root‘, so that this daemon actually runs as user ‘
root‘, and to put into the limits file:
root hard memlock unlimited root soft memlock unlimited
Once I had done that, the daemon was able to run, with the option set, to pin its pages in RAM.
My corollary of the initial problem is as follows:
When the system boots, non-default limits are taken for user ‘
root‘ from the file(s) ‘
/etc/security/limits.conf‘ . But it does not seem to be part of the default behavior of Debian, to load the limits for non-
root users. Indeed, after a
root process downgrades its user-name – say to ‘
memcache‘ – In order to protect security, the real behavior of the kernel seems to be, just to do a reset of the limits of that process.
Now, an exception can be created, by adding the following line at the end of configuration file ‘
/etc/pam.d/common-session‘, to state
session required pam_limits.so
However, while this does load the per-user limits, it only does into effect when a user-name belonging to a real person does a log-in, and when this log-in uses ‘
PAM‘ to authenticate the user. This happens via
SSH when enabled on the side of the server, as well as for KDE users. Hence, on my laptop ‘Klystron’ it worked brilliantly to remove one error-message associated with ‘
jackd‘, because it was set for a group of users – who actually log in.
But for the system user ‘
memcache‘ it seems to do nothing, since that user does not go through any type of authentication at all. An instance of this user only comes into existence, because ‘
root‘ has dropped its privileges.
And I feel that this is how the need arose, for me to run ‘
memcached‘ as user ‘
Now I suppose that a more practical question could arise, as to why my blog benefits from this daemon, which only listens on a local port for incoming connections, that ask it to cache arbitrary objects.
And the answer is, that my
WordPress engine has the plug-in installed, which is named “
Memcached Is Your Friend“.
So what actually happens in the case of my blog, is that multiple
Apache sub-process can be created, to allow multiple readers to connect, but that all these sub-processes execute the same PHP Scripts, which in turn access the same
MySQL database to retrieve my actual blog.
But then, thanks to this plug-in, each script-instance can connect to the same ‘
memcached‘ daemon running, where certain fragments of HTML are cached, that once resulted from the execution of the PHP scripts. And I do believe that this accelerates the retrieval of bits and pieces of my blog – Provided that someone has been reading the same fragment of HTML before, and that that fragment has not been evicted from the daemon, say because there is not enough memory allocated to cache everything.
Now I suppose that another question a curious reader might have, could be, ‘Why was Dirk unsure that this arrangement would work after a clean boot, when it seemed to work during a session of tinkering?’ The answer would be as follows:
If I restart ‘memcached’ manually, it is by doing the following:
dirk@Phoenix:~$ su Password: root@Phoenix:/home/dirk# cd /etc/init.d root@Phoenix:/etc/init.d# ./memcached restart (...)
The glaring problem here is the first command: ‘
su‘. I am establishing that I am
root, using an authentication from a shell. In this environment, it is also possible to give the command
Before I made any changes to ‘
/etc/security/limits.conf‘, and while I was
root, the response came that I was limited to locking 64K. After I had modified the limits file, the output changed to “unlimited”.
But both when querying the kernel with the command, and while I was restarting ‘
root session was inheriting the privileges which came from my authenticating as
root. I had no way to know that these modified privileges would also be in effect, after a reboot, and without my having restarted ‘
memcached‘ manually. And so this recent reboot I did was also a chance to see, that this daemon would run correctly, with its memory locked, and without my having had to do anything manually to make it so.