No space left on device - /tmp/ruby_sess.938af5ba9b9a02ed

Rails Deployment
1

Every week or couple weeks, my application goes haywire, and in my
production.log I get,

No space left on device - /tmp/ruby_sess.938af5ba9b9a02ed

Visiting the site, it looks like it refreshes every second.

Any ideas? I am not running out of physical HD space, so this is
confusing.

2

jcontonio wrote, circa 2007-03-26 1:23 PM:

Every week or couple weeks, my application goes haywire, and in my
production.log I get,

No space left on device - /tmp/ruby_sess.938af5ba9b9a02ed

Visiting the site, it looks like it refreshes every second.

Any ideas? I am not running out of physical HD space, so this is
confusing.

I’m assuming this is on Linux, and that you’re running with the ext3
file system, but feel free to correct me if I’m wrong. It’s possible
that you’ve run out of inodes – using the file system for session
storage results in the creation of mind-boggling numbers of files, and
that can exhaust the file systems inode resources quickly. Check the
output of:

df -i /tmp

and see what it says under “IFree”.

Hope that helps,
Jeff

3

Actually FreeBSD but you’re exactly right. What’s the best way to
solve this?

4

jcontonio wrote, circa 2007-03-26 4:49 PM:

Actually FreeBSD but you’re exactly right. What’s the best way to
solve this?

My FreeBSD knowledge isn’t particularly keen so I probably can’t be of
much help, but it’s entirely possible that you might not be able to
adjust the inode count of a UFS volume without reformatting the volume
or slice. You can’t with ext3, either, as far as I’m aware. If you do
have the luxury of being able to re-create the file system – such as if
/tmp is a file system all its own and you can move the data off of it,
unmount it, reformat it, remount it, and move the data back all in a
relatively short period of time with no services running – then you
could use the -i and -f options for /bin/newfs. Doing something like -f
1024 -i 1024 should give you a reasonably usable file system for doing
file-system-based session store, but that’s an awful lot of trouble to
go to for what’s basically provided as a lowest-common-denominator way
to store session data

My recommendation – for this reason and for many, many others – would
be to switch to the ActiveRecord session store. Ideally, if you’re
using MySQL, use a MyISAM table (rather than InnoDB, which is a more
advanced table format with transactions and other such features you
don’t need for an AR session store table). I suspect I’m not alone in
recommending this, either, but if there are reasons you can’t do so with
your application I’d be interested in hearing them as there are other
session store options available which might better meet your needs.

Thanks,
Jeff

5

Two recommendations:

  1. Do not use file system for sessions storage in production. It’s VERY
    slow
    and leads to problem like you outline.
  2. Once you change session storage to ActiveRecord, be sure to clean up
    stale sessions on a regular basis.

Alex Verkhovsky

6

Depends on the filesystem - for ext2/3, the number of inodes are fixed
at fs creation time, while some (like reiserfs, I believe) don’t have a
fixed number of inodes. Not a BSD guy, but the same issues apply.

Either way, it would require the filesystem be reformatted.

Of course, you could just delete some files =) You are deleting old
session files, right?