DCOPServer errors on eeepc - FIXED
John McKee
DCOPServer errors.
First thing I looked at was /var/tmp. The directory has the sticky bit set. I
preseme that is to prolong the life of the SDHC by spreading the wear. Maybe
so, but the directory grows over time. It gets so bad that rm -r fails due to
lack of space.
Another place to look is the .xsession-errors file. It also gets very large.
Finally used the right words in Google to find the reste of the issue. Buried
on the eee users site was a lot of discussion about DCOPServer errors. One
"fix" was to essentially reinstall the base operating system. I'm not sure
what gets trashed by that process.
Further down is the real story. I had been using df with no arguments and
seeing 64% free. And wondering how come the disk was reporting as full. I had
forgotten about inodes. For some reason, again, maybe to spread wear on the
SDHC, inodes re not released. That was evident by running df -i and seeing the
used inodes at 100 percent.
The fix was to remove files that had been created to hold the inodes. The
process took a long time. I was concerned that I was turning my notebook into
a brick. But, it is just fine now.
A procedure was given to release the inodes, which were being held with
filenames starting with .wh - those things are all over the place. I ran the
procedure first to list the files, and it was a huge list. I did not look at
the entire list, but ran the commands to remove the files. Instead of 100
percent used, I am down to 15 percent.
I was lucky that a mount point was available to use, as I could not create one
anymore.
Here is the segment from the page, the url will follow if anybody is inerested.
Code:
#!/bin/bash
# Create directory if needed (never hurts)
sudo mkdir -pv /mnt/sda2
# Mount /dev/sda2 into our new directory
sudo mount /dev/sda2 /mnt/sda2
# Delete the stupid .wh* files
sudo find /mnt/sda2 -iname '.wh*' -delete
# Don't forget to clean up
sudo umount /dev/sda2
And the URL:
http://forum.eeeuser.com/viewtopic.php?id=31194#p303854
I hope thhis helps somebody else.
John McKee
Jeffrey Watts
J.
First thing I looked at was /var/tmp. The directory has the sticky bit set. I
preseme that is to prolong the life of the SDHC by spreading the wear.
The sticky bit needs to be there. It prevents one user from clobbering another user's temp files. This is standard across most (all?) Unixes. /tmp is the same way.
The fix was to remove files that had been created to hold the inodes. The
process took a long time. I was concerned that I was turning my notebook into
a brick. But, it is just fine now.
You misunderstand what inodes are. Files don't "hold" inodes, inodes are the files themselves. Files and directories are comprised of an inode plus zero or more blocks to hold the data. The inode contains things like the permissions, how many links there are to it, and the addresses of the blocks where the file contents are stored. So you can think of an inode as being the map of the file.
A procedure was given to release the inodes, which were being held with
filenames starting with .wh - those things are all over the place. I ran the
procedure first to list the files, and it was a huge list. I did not look at
the entire list, but ran the commands to remove the files. Instead of 100
percent used, I am down to 15 percent.
Your problem is that you are running Xandros, it uses UnionFS, and it does not clean up after itself. I gather there must be a good reason they're using UnionFS, but the fact that they're not deleting .wh* files when they are no longer needed is a big problem. My guess is that they figure folks just won't use the systems that long. You will need to turn on cron and add that cleanup script to your crontab so that it gets cleaned up frequently.
It looks to me (at first glance) that the distribution just isn't set up well. Cleaning up /tmp is a very basic thing that should be automated, and if they aren't doing it it's a big problem.
Your other alternative is to boot off of a CD/USB and rebuild the filesystem so that it has more inodes. I'd suggest increasing the amount of inodes by a factor of 4 if you do this. The downside of doing that is that you'll lose some disk capacity, as in most Unix filesystems (all?) inodes are allocated at filesystem creation and the amount of space allocated for them can't be changed. It shouldn't be a dramatic loss, however.
I'd recommend just cleaning up the .wh files. However, I'd find out exactly what they're being used for before just blindly deleting them. Also, I would not use the scripts they provided without modification. Those folks are deleting all files named .wh, without consideration to atime (last accessed time) or mtime (last modified time). If you don't want to bother finding out which ones are safe to delete, at least use a mtime parameter to find so that you don't delete files used recently.
Here's how to find and delete all files named .wh that haven't been modified in over 5 days:
find / -name ".wh*" -mtime +5 -exec rm {} \;
You can also do the -delete option, but that's probably a GNU-ism, and isn't portable between Unixes. I prefer to use OS-neutral commands whenever possible. While you probably should use atime instead of mtime, I suspect that on your system they have atime turned off so as to minimize writes to the flash drive.
Jeffrey.
--
"He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself." -- Thomas Paine
John McKee
used. Adding -i showed 100 percent used. My notebook was close to useless as
no inodes were available. I got the terminology wrong. Been a long time. A
directory entry consists of the name and an inode number. An inode is
assigned
to each block. The df command was reporting space available, but all the
inodes were considered allocated.
I was EXTREMELY nervouse about what I did. Especially when it took nearly a
half hour. But, since I got that information from the eee user forum, and it
had been ollowed by replies that all was well, I tried it. Had this not been
on the eee user forum. I am pretty sure I would have been unlikely to
send off
a rm like that. EXTREMELY dangerous and downright stupid at times.
Now, why or how Xandros created that mess is another issue. I have to wonder
how many notebooks have been dropped into the trash due to this.
Thepitch from
Asus seems like this is never a problem. That gives Linux a bad rap. I had
read where Linux notebooks were being returned at a higher rate than the
*other* OS. This may be a nasty reason. And, that is a shame. It is not
obvious that the eeepc runs Linux, unless a console is opened. No tricky
commands to remember. Works "just like Windows" as long as the GUI is
used. This nastiness does not make Linux acceptable for people who
barely can deal
with the issues of Windows. If tis mess is specific to Xandros, it is a BAD
distro. If it was customized by Asus and made bad, then Asus not only shoots
themselves in the foot, they also attack Linux.
I had read somewhere that the expected life of the eeepc was about a
year. The
thinking was that the SSD would fail. Apparently, that was all
misguided. For
one thing, it was stated, somewhere, that the eeepc used ext2. Turns
out, that
is only party correct. The read only portion of the SSD is ext2. The
rewriteable portion is ext3. As far as unionfs, that allows software to be
upraded, within limits. In that respect, it is a good thing. But, this unit
came with *only* 4G and after OS was allocated, had 1.2G free. Pitifully
small. Which was recognized by Asus, as they moved up to 20G. As long as
Xandros does not releae inodes, the future is delayed on when it will brick.
In this case, things were so bad that I was in danger of not being able to do
anything, especially going online for help. It is hard to believe just how
mush a part of life a Google search is anymore. My training was way
before the
Internet, where you counted on the kindness of strangers (technical support),
when it existed.
John McKee
Jeffrey Watts
I appreciate your comments. Running df with no parameters showed 64 percent
used. Adding -i showed 100 percent used. My notebook was close to useless as
no inodes were available.
The reason that inode usage% is not shown by default is that filesystems are allocated with more than sufficient inodes on creation. Usually the only time inode usage is considered is on high-end servers doing specialized work, either reducing the amount of inodes on systems with few very large files or increasing them on systems with lots of little files.
It's one of those trivia questions for senior sysadmins, and well designed distributions manage temporary files appropriately.
I got the terminology wrong. Been a long time. A
directory entry consists of the name and an inode number. An inode is assigned
to each block. The df command was reporting space available, but all the
inodes were considered allocated.
No, blocks are assigned to inodes. Inodes can link to more than one block (and usually do). Different Unixes and filesystems may have slightly different terminology for the allocated storage (fragment, etc). Otherwise correct.
Here is how storage is allocated for an 8k file. Let's assume that the allocation unit is 2k (block, fragment, whatever). You will have the following:
* One inode of a fixed size. Contains file information like permissions, how many links there are to the file, mtime, atime. Most importantly, it has the locations of the allocated storage to hold the contents of the file.
* Four 2k allocation units, containing the contents of the file.
A four gigabyte file and a 0 byte file both use one inode. The reason you are having the problem you're having is that UnionFS is leaving LOTS of tiny temporary files around that are not being cleaned up for some reason, most likely due to some failure of Xandros.
John McKee
used space is 50 percent. Lowest in a LONG time. Used i-nodes is 15
percent. A huge amount of space was tied up. Would this be same on
another distro, such
as Ubuntu, if unionfs was used?
Matthew Powell
I've never experienced anything like what you describe with my EeePC(901). But then again, I booted it up to Xandros and nearly threw up. Then I installed debian (works flawlessly, BTW, especially with 2.6.29). I'm also immune to the DCOP related problems as I waffle between xfce and gnome and don't touch the KDE stuff.
I did a little checking on UnionFS. From http://en.wikipedia.org/wiki/Union_mount:
"Rather than mounting each filesystem at a different place in the directory hierarchy, a union mount overlays the filesystems, creating a unified hierarchy. Thus, any given directory (or "folder") in the resulting filesystem may contain files and subdirectories from any or all of the underlying filesystems."
I'm not a filesystem expert, but I thought the traditional way of mounting filesystems in *nix was pretty solid, this seems like a bad idea to me.
My guess is that the Eee-ized version of Xandros (again, eww) employs this filesystem because several Eee models actually contain two SSDs, one hardwired to the mainboard and one in an expansion slot. I can see the value of them being treated as one big filesystem (especially on XP, actually). Again, I'm no expert. That said, I'd still prefer to do it the old fashioned UNIX way. Maybe I'm missing something.
Anyway, just for reference, here are the df stats from my 901 running debian.
squirt:~$ df -T|grep -v tmpfs|grep -v udev
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/sda1 ext3 3763404 3156932 415300 89% /
/dev/sdb1 ext3 13551352 7021836 5841136 55% /home
/dev/sdc1 vfat 15685632 15024096 661536 96% /media/sd
squirt:~$ df -i|grep -v tmpfs|grep -v udev
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 239040 151653 87387 64% /
/dev/sdb1 861568 42093 819475 5% /home
/dev/sdc1 0 0 0 - /media/sd
squirt:~$
HTH,
Matt
Austin Morgan
----------------original message-----------------
From: "Matthew Powell" ma...@linuxfriends.net
To: kul...@googlegroups.com
Date: Thu, 14 May 2009 13:09:39 -0500
-------------------------------------------------
UnionFS is most commonly used to overlay a read only file system with a
read/write file system in an attempt to make it act the way one would
expect. This is a very useful means of doing things. Oddly enough it also
fits very well in to the UNIX way of doing things due to the fact that the
underlying File System is optimized for it's need, and UnionFS sits on top
and extends the functions of the underling FS. Of course like anything else
it can be abused.
Austin
Jeffrey Watts
Again, the problem appears to be with Xandros, which isn't surprising.
Jeffrey.
I am wondering if the implementation of unionfs is the real issue. Right now
used space is 50 percent. Lowest in a LONG time. Used i-nodes is 15
percent. A huge amount of space was tied up. Would this be same on
another distro, such
as Ubuntu, if unionfs was used?
John McKee
Is the behavior of renaming file with a .wh prefix part of unionfs? I
read some
on unionfs and did not see that behavior mentioned. Might not have looked in
the right place. Or, is file renaming a Xandros or Asus thing?
John McKee
Jeffrey Watts
Is the behavior of renaming file with a .wh prefix part of unionfs? I
read some
on unionfs and did not see that behavior mentioned. Might not have looked in
the right place. Or, is file renaming a Xandros or Asus thing?
Either way you can see my above suggestions as to how to deal with the problem.
Jeffrey.
John McKee
> On Thu, May 14, 2009 at 2:09 PM, John McKee <jmm...@flinthills.com> wrote:
>
>>
>> Is the behavior of renaming file with a .wh prefix part of unionfs? I
>> read some
>> on unionfs and did not see that behavior mentioned. Might not have looked
>> in
>> the right place. Or, is file renaming a Xandros or Asus thing?
>>
>
> Yes, it is. I'm not sure what causes it to not clean up, though. If I had
> to guess I'd imagine that the .wh files were the delta files from the
> read-only filesystem, and the .wh files left in /tmp and /var/tmp are deltas
> of temp files, which obviously can be removed after they're no longer in
> use. I believe I saw somewhere that Xandros on the EEPC doesn't run cron by
> default, so my guess (lots of guesses here) is that they're not running a
> standard cronjob to clean up tmp, which is not good practice.
>
> Either way you can see my above suggestions as to how to deal with the
> problem.
>
> Jeffrey.
>
> --
The really surprising thing is just how widespread the .wh files were.
None in
/tmp or /var/tmp. I didn't keep a log of where those things were, especially
since I felt lucky to even be able to run find to look for the things. Some
may have been dropped there by doing an update. Crying shame that they
weren't
moved to a common area or just deleted outright. As I said before, this does
not make Linux look like the superior OS compared to the stuff from
Redmond. A
ticking time bomb like this just makes it all too easy for somebody to hang a
label on all Linux distros, based on very bad experience with one.
I can't remember whwer I read it. Might have been kulua. Somebody
commented on
how files could not be deleted from the eeepc. Now, I know what is
really going
on. I have not looked at the rc stuff on the eeepc. It >might< be
possible to
put something in rc.local, assuming Xandros uses that mechanism. Something I
will look into, as much as I use it.
Can you tell me what the purpose of .xsession-errors is? The standard was to
just append to that file. It also got huge. One the same page where I
learned
about the .wh mess, it was suggested to change the append to overwrite.
Assuming .xsession-errors is of any value, it would seem a better idea
to
maintain a few versions and rotate them, instead of just letting the file grow
huge, or truncating it at start of each session.
John McKee
Jeffrey Watts
moved to a common area or just deleted outright. As I said before, this does
not make Linux look like the superior OS compared to the stuff from
Redmond. A
ticking time bomb like this just makes it all too easy for somebody to hang a
label on all Linux distros, based on very bad experience with one.
Well, Xandros has a bad rep for a reason it seems. And it's not just their unholy deal with Microsoft.
I can't remember whwer I read it. Might have been kulua. Somebody
commented on
how files could not be deleted from the eeepc. Now, I know what is
really going
on. I have not looked at the rc stuff on the eeepc. It >might< be
possible to
put something in rc.local, assuming Xandros uses that mechanism. Something I
will look into, as much as I use it.
That would work if you're booting a lot. Are you booting or just suspending? If the former, cool. If the latter, run cron.
Can you tell me what the purpose of .xsession-errors is? The standard was to
just append to that file. It also got huge. One the same page where I
learned
about the .wh mess, it was suggested to change the append to overwrite.
Assuming .xsession-errors is of any value, it would seem a better idea
to
maintain a few versions and rotate them, instead of just letting the file grow
huge, or truncating it at start of each session.
Well, .xsession-errors is where your X session, um, error messages go (it's kind of obvious). If it's growing too big too fast you might look and see what the errors are and fix them. If you don't care, do the following:
link -s /dev/null .xsession-errors
Delete your original first.