You are not logged in.
Hi
Since last update, I'm having the following problem:
sometimes my archLinux becomes very slow and telling from disk activity it swaps like hell. I investigated a little, and discovered that when this happens, there are two 'ld-linux.so'-processes running, each eating about half of my RAM (512 MB)! Today I was in a somewhat insane mood and tried to kill those processes (from teminal). After that the system returned responsive, but KDE was frozen. Once restarted X (ctr-alt-canc) everything worked well again.
I know, all this is pretty vague, but I can't give more details, since I don't know where and how I should make further investigations.
Any hints? Is 'ld' the culpable? KDE? xorg? or maybe the ati fglrx proprietary driver I'm using for my graphics card? (had problems with that beast before...)
Before you ask me: I found no Information in 'dmesg' nor in log files..
tnx
Simon
Last edited by lupylucke (2007-10-29 22:57:55)
Offline
My gut tells me that's a rootkit. ld-linux.so isn't a process... it doesn't have an entry point. Try running chrootkit, and let me know if it finds anything.
Offline
Things I would do.
1. Disconnect your network (physically)
2. Do a find on your filesystem to see where that binary lives. Compare the md5sum on that file to that of the one in the pacman package.
3. Run lsof on the processes and see what they are touching.
4. Try to attach strace to the process and see if you can figure out what it is doing.
5. Boot a livecd and mount your partition. Maybe do a rootkit checker on it.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
chkrootkit didn't find anything...
I realize now that my previous post wasn't exact: in fact the process wasn't named ld-linux.so but ld-linux.so.X, where X is a number, unfortunately I don't remember what number...
I did a
find / -name "*ld-linux*"
only three files by that name exist: two manpages (ld-linux.8.gz and ld-linux.so.8.gz) and /lib/ld-linux.so.2 (member of package glibc). I checked the md5sums of all three: everything's OK.
Offline
Whenever that process is running, go to /proc/[pid] to retrieve some additional information about the process. Scriptkiddies use tricks to set the cmdline which is read by ps auxw. You can ls -la the /proc/[pid]/ directory and find out which binary it is by looking at where the "exe" binary links to.
Offline
I had this happen to me, I seem to remember it being related to Acroread.
Last edited by elliott (2007-10-30 08:52:59)
Offline
elliott: do you remember how you solved your problem? Now that you made me think of it, it might well have something to do with acroread. I remember that when it happened I was using acroread. Yesterday and today I didn't use it and everything works fine...
Offline
Had a similar problem about 2 weeks ago. Re-installing glibc solved it for me.
---for there is nothing either good or bad, but only thinking makes it so....
Hamlet, W Shakespeare
Offline
I looked a bit at the problem (thanks to elliott for the hint about acroread) .
I found out that it's not a rootkit : examining the suspicious process, it turned out that it has effectively to do with acroread (I'd say a really bad memory leak):
$ ps -f -C ld-linux.so.2
UID PID PPID C STIME TTY TIME CMD
simon 9582 1 9 13:59 ? 00:00:36 /lib/ld-linux.so.2 /opt/acrobat/Reader/intellinux/bin/acroread --display :0.0 -progressPipe 3 -exitPipe 4
As we can see here, the acroread binary isn't started directly, but with /lib/ld-linux.so.2. Taking a look at the startup script of acroread (/usr/bin/acroread) confirmes that. According to its manpage, ld-linux.so can effectively be used to run binaries.
The thing seems to be related to konqueror: opening pdf documents directly with acroread, I couldn't reproduce it; it occurs only when opening them in konqueror (acroread embedded in the konqueror window). How to reproduce it:
- open two konqueror windows (or split one in two)
- have a konsole or something similar running top, to monitor what's happening
- open a pdf document in each window by just clicking on the icon
- at this point a process named ld-linux.so.2 should appear in the output of 'top', probably it wont stay on top of the list for long time
- click the "back" button on one of the windows
At this point two things may happen:
- the ld-linux.so - process gets defuncted, the document that is still open will no longer be displayed. Trying to open again a pdf document in one of the windows will result in an error message saying "Unable to load Netscape plugin for file:///some/path.pdf". This looks like a bug in konqeror to me
- the ld-linux.so-process stays alive, and slowly begins to eat up memory and, if you don't STOP or KILL it, it will go on until the memory is full.
My question now is: can anyone reproduce that on his system?
If it is confirmed, where to file a bug report, acrobat or konqueror? both?
kishd: re-installing glibc was also one of the first things I did, when this turned up, but it didn't solve the problem. And from what I found out I'd say that it's definitively not a problem of glibc...
Offline
It seems Adobe is aware of the problem, there is some discussion about it on this page:
http://blogs.adobe.com/acroread/2007/09 … der_1.html
Offline
It seems Adobe is aware of the problem, there is some discussion about it on this page:
http://blogs.adobe.com/acroread/2007/09 … der_1.html
Hmm... I'm not sure they're discussing the same thing there. My problem is about memory and not CPU usage...
Offline