I can't delete that /var/tmp folder because of the DCOPserver error saying there is no disk space left to delete...



This DCOP thing is really starting to irritate me...it happens once every 4-5 weeks...

I'm getting a similar problem, except I don't have midnight commander, so i just attempted the code in the folder, and it says "rm: cannot remove directory `/tmp/': Device or resource busy"

Is there something I'm missing or do I have to do F9? I'm also not able to copy my data over to my SD card or flash drive. The devices show up, but not the contents of them.

edit- Solved the problem. Initially when I removed the folder, I didn't have root access, so it didn't do a clean job, did it a second time under root, and worked like a charm.

Last edited by danucleus (2008-03-10 7:59:59 pm)

@ bobby_1290

Following your instruction re the DCOP issue saved my day.
Just wanted to say thank you.

*nods* Thanks everyone!

         cd /var
         sudo rm -rf tmp

seemed to solve this for me. First time this error has happened on my system (since November!). This is a great forum

Hi, Last try before I just accept it as part of the big inevitable in life (cf. Murphy's Law and its corollaries). As the dcopserver error messages have started to come back again although I F9ed recently (remember: everything's fine except for the annoying messages) and as, furthermore, they can, for some time, be prevented from popping up by deleting xsession-errors and DCOPserver* files, I would like to submit the following humble idea to you Linuxites out there: Why not write a script whereby those files are deleted automatically?

MakaniMike wrote:

I had the feeling that the key to the success was the start-ups without power (neither battery nor AC) I did in between to purge any residual stuff flying around.

Sorry, forgot to ask. How is a start-up possible without battery or AC? Have I missed something?

Question:  Do I have to be running eeepc in advanced mode in order to remove files under root?  This is my first experience owning a linux-based os, and I haven't the first clue on how to do so. . .I attempted to "delete" the latter specified files on this topic (dcops server and x whatever ) only to see the option "delete" not highlighted (grayed out) when I right clicked.  Hence, I can't delete "****."

My eeepc is a 4 gig 701, and as I have no idea how linux functions, I haven't tweaked one thing on the computer.  It is at factory settings--exactly the way it came out of the box, and yet, this frustrating dcops error has rendered the entire computer virtually useless; I can't connect to the internet (main problem), and basically just can't open ANYTHING without having that stupid dcops server flash on me and then having the computer crash . . .

PLEASE HELP!

Actually, you shouldn't use sudo rm -rf tmp in /var/, as at least on my EEE it killed xkeyboard so I lost my keyboard settings and I'm unable to restart the service.

I guess I'll back up the system as it is now, do a system restore, enable adv. mode and reload my settings.

The removal of the directory  /var/tmp as described in this post fixed the problem I was having (similar or the same as described by MakaniMike and bobby_1290).

But I subsequently had problems with WindowsNetwork access using FileManager.

This was resolved by recreating an empty directory ( see http://forum.eeeuser.com/viewtopic.php?id=32642 ):
sudo mkdir /var/tmp
sudo chmod a+wrxt /var/tmp

From what I have found the initial problem is related to the resource limits placed on inodes (?? like pointers to files?). This can be checked using the following command at the terminal:
df -i

As some other users have reported problems in using: 
       cd /var
       sudo rm -rf tmp
a more controlled method to delete the offending files might be to use the root file manager to selectively delete files:
sudo XandrosFileManager

Hope this helps and thanks to everyone who are contributing to this forum!!!

Last edited by rdreeves (2008-06-14 6:48:02 pm)

Most likely you need to do the factory reinstall shuffle like I did. The problem lies in two hidden folders in /tmp/ -- kdecache-root and kdecache-user. They, or files under them, shouldn't be deleted.

I learned from that mistake and now I have a backup on a usb stick when I start to get adventurous again.

I also got the DCOPServer death earlier today, and it seemed very much to be related to the "No space left on device" error, however df -h was showing plenty of space... Nevertheless, I deleted some stuff and that seemed to fix things for a bit, but about two hours later, it was back to the same error.

So I googled up a few answers from this forum, most notably this thread which suggested lack of inodes might be a problem. Lo and behold, df -i was showing zero free inodes, and deleting stuff had just freed a few inodes (I'd deleted few big files, not many small ones).

For background, an inode is semi-equivalent to a FAT entry, in that it's a part of a chain, and it holds directory entries (filename, permissions, owner and group, and possibly other stuff, too). So every file on an ext2 or similar filesystem has an inode, and there is a limited number of inodes.

The other problem was that the unionfs used in stock Xandros automatically creates some very hidden files, named ".wh[something]", apparently creating them whenever a file is deleted, so that the free inode count will always go down, and never up (with the exception of deleting directories (thus explaining why 'rm -r /var/tmp' works -- because you're deleting the hidden files inside it, and /var/tmp gathers many of them) -- and also why it's only a short-term solution.

Thanks to this other thread, I found a way to delete the .wh* files all at once, which should be a much longer-term solution (but, obviously, never a permanent one -- this will have to be repeated). I've posted this solution here (see the CODE box), and can verify the solution not only works, but spares you from having to F9 your Eee incessantly.

The commands can probably be gathered into a script and put into cron, if someone wants to automate the process, however CAUTION: I've not yet verified a system thus "cleaned up" will still function after a reboot. I will return and edit after I test that.

EDIT: Yeah, it worked. To show the difference, this is my inode count now:

/home/user> df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
rootfs                185088   26533  158555   15% /
[remainder snipped, since unimportant]

So this is the solve: 158 thousand (!) free inodes, compared to about 1000-ish that I'd managed to clear up before I came across the idea mentioned (and linked) above. I won't need to do this again anytime soon...

Last edited by Narc (2008-06-30 3:04:22 pm)

This page saved me and I want to thank the people who have posted and the folks who run this site. Thank you.

One thing I noticed that might be of use to people. This began when I plugged in an SD card from a friend's computer and it executed some program that I imagine is supposed to get at the pictures in some way. Had I thought to check this BEFORE inserting it into my Eee 701, I might never have had the problem.

Deleting the xsession-errors file and removing /var/tmp did the trick though I got nervous throughout all of this.

Thank you again for the help. You saved my day.