Proving the Obviously Untrue - php

Garbage collecting sessions in PHP

nospam@example.com (Colin Turner) — Sat, 14 Mar 2009 10:44:09 +0000

In PHP, sessions are by default stored in a file in a directory. Sessions can be specifically destroyed from within the code, for example when users logout explicitly, but frequently they do not. As a result session files tend to hang around, and cause the problem of how to clean them up. The standard way is to use PHP's own garbage collection which is normally enabled out of the box. In this, we define constants that specify the maximum lifetime for the session, and essentially the probability of clean up.

To make things more interesting, Debian, out of the box doesn't do garbage collection in this way. It has a cron job that regularly erases session files in the defined session directory. But, if like me, and many others, you put your session files in a different directory for each application to avoid clashes on namespaces for two applications running under the same browser from the same server, you have a problem. If you forget Debian's behaviour the session files will just grow indefinitely. I had forgotten this issue and found over a year's worth of session files in a directory recently.

Solving this problem is actually quite difficult to do optimally. I mean, I could create a cron job to mirror Debian's own, but then I'd have to put the maximum lifetime in a cron job somewhere, out of the way, and difficult for the average sys admin I'm working with to find and deal with. (That is, away from the main configuration of the project). Or I could parse this value out of the main configuration. But this leads to another problem. For some users, a 30 minute maximum idle time is acceptable (although in my case where actually a suite of applications are being used as a single gestalt entity that can even be a problem), but for many of my administrator users you need huge idle times, since they are used to logging in first thing, and periodically working at the application through the day.

In the end I settled on changing our framework to make it easy to pass through garbage collection values. This makes an interface to the configuration really easy, but it doesn't solve the problems of long session times that not all users need, and huge delays in garbage collection.

In my last article I talked about a Munin plugin for OPUS, but when you look at it you'll see these kind of cliff fall drops, which are caused by the garbage collection finally kicking in and removing sessions where users have not explicitly logged out. Currently, every ten minutes, OPUS runs through its user database and finds users who are allegedly online but have no active session file and then marks them offline. Then it updates the file with the online user count that Munin reads.

I suspect eventually, I will write a more sophisticated script that actually kills sessions depending upon idle time and the user class, which would make for a more accurate picture here. Any brighter ideas gratefully accepted.

Fixing truncated printing with Firefox

nospam@example.com (Colin Turner) — Wed, 16 Apr 2008 23:18:50 +0100

A while ago, I discovered that my current main development project OPUS had an odd problem when printing out of a gecko based browser.

It would print the first page, whether in portrait or landscape, and if there was more content, it would be abruptly truncated and the second page would contain merely the footer off the page. I've been meaning to try and solve the problem with a print stylesheet for a while and finally did so today.
Continue reading "Fixing truncated printing with Firefox"

Drupal Login Problems

nospam@example.com (ct) — Wed, 13 Dec 2006 11:48:37 +0000

So, in order to post that rant about PHP and SimpleXML I had to fix a problem that seems to have spontaneously arisen with Drupal (this content management system). For some reason it wasn't persisting login information, at least from firefox (sorry - iceweasel here on my Debian system). It's interesting to note, reading about the bug, that it has been around for literally months and doesn't seem to have been nailed. So, anyway, I've installed some beta of Drupal, and yes, it now seems to be fixed... If I could only solve the problem that I can't "uncollapse" parts of the content now. UPDATE: OK, this seems to be a problem with firefox version 2, or probably really the CSS file for it. It works with Galeon, or when I tell firefox to fake being IE .

SimpleXML should be called BloodyAckwardXML

nospam@example.com (ct) — Wed, 13 Dec 2006 11:39:00 +0000

Another night of coding in PHP, and I've officially decided that SimpleXML utterly irritates me. I'd already discovered, much to my irritation, that is virtually impossible to handle SimpleXML objects elegantly with the Smarty template engine - but now I discover I can't even shove them in a PHP session without trouble - when you next visit the site you get stuff like this: Warning: session_start() [function.session-start]: Node no longer exists and then more trouble. As part of a new Web Application Framework I'm working on I wanted to parse XML configuration files one time only, and then cache the results in the session. It looks like I now have to totally redesign my idea . You can see the work in progress at its home page.