Glibc Timeout errors - revisited

richard at richard at
Tue Jul 15 09:37:22 PDT 2003

On 2003-07-15 09:50:55 +0000, James Robertson wrote:
> I think this is where you got the info you posted above.  What I find
> interesting is that the author says that "/dev/shm is automagically
> created if you use devfs". I use devfs on my host, but do not have a
> /dev/shm directory or mount present. 

I suspect the mount point is created by devfsd. If you do not run
devfsd, it will not appear. if you 'ls /dev', it will not appear,
but if you 'ls /dev/shm' or 'mount /dev/shm' devfsd can create it.

> What is the difference between POSIX and SYSV
> shared memory?
The commands needed to get at it. You would only really care if you
are programming something multithreaded in a language where you have
to do all the work yourself ('C'). Here is an intro to shred memory:
info '(libc)Memory Subsystem'
info '(libc)Memory-mapped I/O'

> If I try and mount either manually (after creating /dev/shm) or through
> the fstab entry, I get the following error:
> mount: wrong fs type, bad option, bad superblock on tmpfs,
>        or too many mounted file systems.
I use 'mount /dev/shm' after devsfd has started, with this in fstab:
dev_shm /dev/shm tmpfs noauto,nosuid,nodev,noexec

> [FYI the manual mount command was mount -t tmpfs tmpfs /dev/shm]
> This is also interesting.  My host is a bootable CD-ROM running in
> RAMFS.  Here is what my mounts look like:
from /usr/src/linux/Documentation/
      Ramfs is a file system which keeps all files in RAM. It allows
      read and write access.
      It is more of an programming example than a usable file system.  If
      you need a file system which lives in RAM with limit checking use
AFAIK, ramfs cannot swap out, so anything in a ramfs that you are not
using right now is wasting expensive ram chips. Use tmpfs.

> I wonder if tmpfs was turned on when the kernel was compiled?  How does
> one find that out?
Grep your kernel config file:
    $ grep TMPFS /usr/src/linux/.config
or cat you filesystems:
    $ cat /proc/filesystems
    nodev   rootfs
    nodev   bdev
    nodev   proc
    nodev   sockfs
    nodev   tmpfs
    nodev   shm
    nodev   pipefs
    nodev   ramfs
    nodev   devfs
    nodev   nfs
    nodev   usbdevfs
    nodev   usbfs

> OK, here is another tidbit, when I run ipcs, I get the following:
> kernel not configured for shared memory
> kernel not configured for semaphores
> kernel not configured for message queues
> This could be my issue.
Yes it does look outstandingly guilty.

> And last but not least...the error does not come up at all if
> I start my build from scratch from a fresh boot!  What the heck?! 
> Sounds too m$'y for me [me cusses loudly].  I am using a nALFS 1.1.7 
> profile for these builds.  I ruled out nALFS last night when I did all 
> the steps the nALFS profile performs manually from a command line and 
> got the same failure at at the same point, rebooted and did it again (it 
> was a long night) and it worked fine.  I am completely confused now.
Is this a fresh boot with a ramfs root filesystem? Are you just running
out of space on ramfs? 

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list