On Tue, Nov 05, 2013 at 08:34:37AM +0900, Joel Rees wrote: > On Tue, Nov 5, 2013 at 8:16 AM, Tazman Deville <tazmande...@gmx.com> wrote: > > Just since yesterday, I'm seeing this PHP error > > meaning the "No space left on device (28)" you mention in the subject, > I suppose. > > > on the scuttle installation on a little server here > > I have. > > Scuttle is installed from the debian repos. > > The server is running Squeeze still (I know.. > > I should upgrade it, but I'll spend a day ironing > > out dovecot and postfix when I do, so haven't gotten > > around to it). > > > > Now, the device is far from full. > > df -h shows: > > Filesystem Size Used Avail Use% Mounted on > > /dev/sda7 26G 9.7G 15G 40% / > > tmpfs 949M 0 949M 0% /lib/init/rw > > udev 944M 200K 944M 1% /dev > > tmpfs 949M 0 949M 0% /dev/shm > > /dev/sda1 2.8G 85M 2.6G 4% /boot > > /dev/sda5 154G 52G 95G 36% /home > > > > Googling (or dukgoing, or ixquicking) > > just shows a lot of stuff about "duh, your disk is full", > > but it isn't. > > Somewhere, I think on LinuxQuestions.org, I'd > > found something about the aptitude package cache, > > yesterday when this happened, so I did > > aptitude autoclean > > and that seemed to resolve the problem. > > Today, however, it is not working. > > > > The first thing that I check when I get disk full errors but the disks > are not full is the permissions. Sometimes, software just assumes that > any time the system refuses to write it's that the disk is full. > > Then you should check whether you've set quotas up. In Java, there > would be policies to check. And so forth.
I haven't made any user quotas. I checked /tmp, and there's almost nothing in there of any consequence (an empty log file). To look deeper, the full error was Warning: session_start(): open(/tmp/sess_9gct9d1b866iek1p3kmo5oe0f2, O_RDWR) failed: No space left on device (28) in /usr/share/scuttle/www/header.inc.php on line 8 line 8 of the file in question is a "session_start();" I looked at /etc/php5/apache2/php.ini to see where php is storing sessions. The relevant line, session.save_path = "/tmp" was commented out, so I do not know where it WAS storing them. I uncommented the line and restarted apache, however, it seems to have made no difference. Now, that scuttle installation has been on this server for about two years without ever having had such an issue. I can't think of anything that would have changed any permissions related to its sessions, or preventing it to write to /tmp, but since /tmp definitely isn't full, I suppose that seems like something to look at. The scuttle runs as user www-data, as far as I understand, which should have permissions to write to /tmp, no? I'm unclear as to what java policies have to do with this, but I know diddley about Java. TazD -- http://tazmandevil.info taz hungry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105022901.ga3...@myownsite.me
