startx -> FreeFontPath error message
 

Hello everyone,

I'm new to linuxquestions.org and am fairly new to Linux. I use Linux for research related to computational chemistry.
I have run into a new problem which has me flummoxed.
System boots up OK but when it goes to run startx (automatically), it crashes.
The biggest clue from the /var/log/Xorg.0.log file is the final line:

FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing.

Error messages displayed to the screen include the above line, plus:
As “root” the message is “not enough free disk space on /tmp”
As a non-root user, the message is:
“mkdtemp: private socket for dir: No space left on device”

Can anyone guess where the problem is or what I could try next?

I see this error msg has been asked about, several years ago, but I'm not seeing an answer. The suggestion to add (a symbolic link to) session.d into /etc/dbus-1/ did not affect it.

Possibly relevant: The problem occurred after I did a reboot (shutdown -r); it never occurred with a shutdown -h, but now I can't get back to how it was!

If relevant:
Build Operating System: Linux 2.6.18-53.e15 x86_64 Red Hat, Inc.
Current Operating System is: Linux 2.6.18-92.1.22.e15
I'd like to avoid updating, if possible.


Very appreciatively,
David

makes it sound like you have run out of room on your drive. is it possible to boot a live usb and see if that is the issue?

The problem looks like the hard drive partition where /tmp is located is full. Thus on startup Linux cannot get enough space for the system temporary files it needs to run and startup fails. You might be able to get around the problem by booting a rescue DVD, mounting your hard drive, and deleting all files and directories from /tmp.

For the long term you need to periodically clean up /tmp. On my Debian distribution /tmp is emptied on every shutdown. I don't know how Red Hat handles /tmp. Some systems are never rebooted. In that case you should run a cron task periodically to clean the accumulating garbage out of /tmp. Here is a description of that type of solution:

https://stackoverflow.com/questions/...x-ever-fill-up

Here is an explanation of how Red Hat handles /tmp:

https://www.redhat.com/sysadmin/mana...-tmp-directory

---------------------
Steve Stites

Sorry to sound condescending, but the Extended Life-cycle Support (ELS) for RHEL 5 ends coming November, so you'll need to start thinking about updating really soon anyway. And CentOS 5 has been EOL for more than two years.

As for your problem. In addition to what others already suggested. How is your disk partitioned? Is it possible to swap /tmp for another partition?

Thanks so much, startx lives!
 

So grateful to shruggy, jailbait & cordx. For various reasons I had thought being truly out of space was an unlikely explanation (despite df saying so), but with your nudges I went and looked for non-system files and removed a 7 GB hairy tarball and several rpm's from tmp's partition. Sure enough, all is running normally again!

Thank you for the tips on RHEL / Centos. I have a newer system and am about to bequeath this one to a grad student and it will be his problem ;-). Of course I will let him know. I want to keep some installed computational programs, but that can be consistent with upgrading once he is more familiar with the system.