The folks at Brainy Quote tell me that Jacques Santer once said “A quota is always something artificial that can only last for a certain period of time.” Monsieur Santer was clearly never a sysadmin. A quota may be artificial, but it is inviolate and lasts forever.

There are many reasons quotas may be enforced on a system. Perhaps because disk space is limited, or because a particular system is not designed to be a dumping ground for files. Or the admin could just be a real jerk and enjoy inflicting pain on his users. Whatever the reason, quotas always seem to be too small to please the users and can cause real problems when exceeded. I’ve mentioned in the past (here and here) about the woes of too-small quotas, but the latest example is perhaps the most amusing.

A graduate student sent in a request saying that the GNU Ghostview (ggv) program would not zoom in on documents. Apparently it did at one time, but no longer. (For a year or so, she says, which is a long time to not complain about something.) That seemed like a rather odd issue, so I did the basic troubleshooting. I created a PostScript and a PDF file and tried to view then in ggv. Once they loaded, the zoom worked just fine. So I ssh’ed into her machine and tried again. Still no problem. So it must be something specific to her account.

I checked her quota. She was near, but not over, so I suggested she should perhaps clear some space. I also asked her to send me her .cshrc so I could replicate her environment. Nothing looked suspect in her .cshrc file, so it came as no surprised that when I used that, I was still unable to reproduce the problem. I even tried opening a couple of files she was having problems with — maybe my files were simple enough that they wouldn’t be an issue? Nope.

After a few back-and-forths, she tells me that ggv won’t even open now. So I have another look at her quota. This time, she’s well over the limit, and once she reduced her disk usage, suddenly ggv could zoom in on files again.

So why does this happen? I can only assume ggv needs to write some temporary files when it zooms, and when you’re near quota it can’t. Of course, we said above that quotas are artificial. Disk space, however, is very real, and on a system with no quotas but a lack of disk space, you’ll see similar issues (and probably many others). Often when you’re at or near quota (or nearly out of disk), you won’t even be able to log in with a graphical session because your desktop manager won’t be able to write the temporary files it needs to operate.

What’s the lesson to be taken from this? In an environment such as mine, where the quotas are small and out of your control, always assume that an inexplicable problem with a graphical program is quota-related until you can prove otherwise.