[jindrich]

i was playing around with iphoto. exported a slide presentation to idvd only as an example.
after some play with idvd quited both programs, maybe idvd was still doing something.

since then i got a perl process taking the full cpu.
restart or turning off and on again does nothing.

the perl process starts again, even after a restart and takes all my cpu.

HELP

[jindrich]

more data..
i got into activity monitor. locate the perl process, wich belongs to the system, and try to force quit. asks for pw, and i force quit it.
a few seconds later it starts again.

cant get rid of it,

please help. my powerbook is suffering with fans turned on and getting hotter by the second

[jindrich]

update...
i think i finally killed it.

started to kill every single root process wiith a perl name or similar, it started again but did it faster until i got rid of them.

now the computer seems to have calmed down.

all is silence. alles klar.

what could have caused that? i didnt do anything out of the ordinary.
Maybe idvd let a process hanged out, WRITTEN TO DISK, so it would start even when restarting or killing it

sounds like a virus.


i'm reinstalling tomorrow

[Big Mac]

What was the name of the perl script and from where was it being run? You say it was being run as root? Unless there was a root compromise, which would be big news, it's safer to assume it was some daughter process run amok. Be sure to record as much information as you have about it.

[Millennium]

If you go in through the command line and use ps -aux, you get a list of all the process and their parents -that is, the processes which spawned them. You get all this information through the PID, Process ID. You can then use kill (pid) to kill the process.

Generally speaking, if a process keeps getting respawned, you can stop it by killing the parent. Doing this kills all of the parent's children as well, and the parent won't be able to respawn it. Just remember: whatever you do, never kill the process with a PID of 1. Just don't. That would get nasty.

[jindrich]

hi again.
the powerbook (1.25) is ok now. the perl process didnt activate again.

i'm afraid is too late to recap info on what happened. i dont know much about unix yet. is there a way to get into processes history to see what went wrong?


when the fans turned on -they hardly ever do, i opened a terminal window a typed "top -d" to see what was going on.
saw under the column "COMMAND" a process named "perl" wich was taking all the cpu. i dont remember wich PID it had. No other process with a perl name were on this window.

didnt know what to do. killed everything -including the finder, from "force quit" on the apple menu. the perl process was still alive kicking.
Restarted the computer. after 10 seconds the perl self-started, and took the whole cpu.
Turned the computer off. Turned it on after 20 seconds of waiting. Again, the perl script came to live shortafter the finder was responsive.

Went to the activity monitor (didnt think of that earlier) and saw a process named "perl" with "root" as user, eating the whole cpu.
I killed the process. it asked for and admin pw, gave it and it killed the perl. OK, but after 10 seconds it started again.
I Killed the process once more and looked for something else. I saw another "perl" process, which had hardly any cpu useage, I killed it as well.
The original cpu hungry perl started again. i killed it once more....

...calm.

when i restarted the powerbook to try solve the problem i had 50 processes on (only activity monitor and a terminal window as opened apps). system cpu was at 99%, the moving graphic was in full red, fans fully on.
temperature: boiling level

as i said, i dont know the PIDs of those 2 perl processes.

again, i didnt do anything out of the extraordinary. I had safary and mail open, and played with iphoto. Exported a slide presentation to idvd, played a little with idvd, and quit both apps.
then the perl inferno started.

first time i see something like that in 12 years of mac use. Well, osx wasnt around then ;-)

[Thinine]

It may have been a maintenance task, depending on what time it was. Probably could have let it run.

[Big Mac]

A perl task does not sound like something that would be performing maintenance. jindrich was right to be suspicious.

[jindrich]

Originally posted by Thinine:
It may have been a maintenance task, depending on what time it was. Probably could have let it run.

i have never ever seen a single process taking 99% of cpu resources, even less a maintenance one.

had i let i run, my powerbook would have melted in a couple of hours.

strange, very strange.

[Millennium]

Originally posted by Big Mac:
A perl task does not sound like something that would be performing maintenance. jindrich was right to be suspicious.

Actually, many Unix sysadmins use perl and its ilk to perform system maintenance, as it makes excellent "glue" between other tools. I know for a fact that some important bits of OSX are done in perl, and a lot of the code for faxing is written in Python (which is why Python has CoreGraphics rendering capability in Panther; they needed it in order to write the fax code).

However, for a maintenance task to be taking up that much CPU time definitely doesn't smell right. That's cause for alarm in and of itself.

[Big Mac]

Originally posted by Millennium:
Actually, many Unix sysadmins use perl and its ilk to perform system maintenance, as it makes excellent "glue" between other tools. I know for a fact that some important bits of OSX are done in perl, and a lot of the code for faxing is written in Python (which is why Python has CoreGraphics rendering capability in Panther; they needed it in order to write the fax code).

However, for a maintenance task to be taking up that much CPU time definitely doesn't smell right. That's cause for alarm in and of itself.

Interesting. I guess I should not have made such a blanket statement concerning perl. I should have stated that I have never seen a process with perl in its name running on my systems. I also did mean to add that a maintenance script should not be taking up so much processor time. (I was pressed for time when posting that reply.) A maintenance script should be assigned very low priority. So either some system script on jindrich's PB went crazy, or he truly got hit by some sort of malware. Strange.