ps command not working
September 19, 2006 1:51 PM Subscribe
My process status command (ps) has stopped working in Mac OS X. Help?
/bin/ps: cannot execute binary file is what I get when I try to use ps.
I checked the permissions:
-rwsr-xr-x 1 root wheel 31932 Mar 20 2005 /bin/ps
And compared it to another machine with working ps, looks right.
I'm puzzled, and aggrevated. I've shut down, restarted, sleep'ed... Nothing works.
I'm wondering if this has something to do with my password box not coming up anymore when waking from sleep and screen saver (the option is checked, but it just bypasses the password box).
/bin/ps: cannot execute binary file is what I get when I try to use ps.
I checked the permissions:
-rwsr-xr-x 1 root wheel 31932 Mar 20 2005 /bin/ps
And compared it to another machine with working ps, looks right.
I'm puzzled, and aggrevated. I've shut down, restarted, sleep'ed... Nothing works.
I'm wondering if this has something to do with my password box not coming up anymore when waking from sleep and screen saver (the option is checked, but it just bypasses the password box).
Response by poster: I have not, and that was my next step before doing a reinstall (which I really don't want to do)
Any idea if I need to reinstall it from the same machine, or would the same version be ok? I know some apps sometimes are compiled for specific machines. I'm on a 12" PowerBook...
posted by jasmeet at 2:02 PM on September 19, 2006
Any idea if I need to reinstall it from the same machine, or would the same version be ok? I know some apps sometimes are compiled for specific machines. I'm on a 12" PowerBook...
posted by jasmeet at 2:02 PM on September 19, 2006
Response by poster: I can't even do a ps --version to find out what version I'm at. Oy.
posted by jasmeet at 2:04 PM on September 19, 2006
posted by jasmeet at 2:04 PM on September 19, 2006
when you type "which ps" does it tell you you are running the copy you think you are?
posted by advil at 2:11 PM on September 19, 2006
posted by advil at 2:11 PM on September 19, 2006
Response by poster: [jasmeet@Argentum jasmeet] > which ps
/bin/ps
posted by jasmeet at 2:12 PM on September 19, 2006
/bin/ps
posted by jasmeet at 2:12 PM on September 19, 2006
Response by poster: [jasmeet@Argentum jasmeet] > file /bin/ps
/bin/ps: setuid ISO-8859 text, with very long lines, with no line terminators
posted by jasmeet at 2:19 PM on September 19, 2006
/bin/ps: setuid ISO-8859 text, with very long lines, with no line terminators
posted by jasmeet at 2:19 PM on September 19, 2006
For reference (since I have to go somewhere), it should say something like:
/bin/ps: setuid Mach-O universal binary with 2 architectures
/bin/ps (for architecture i386): Mach-O executable i386
/bin/ps (for architecture ppc): Mach-O executable ppc
if you have 10.4.7, or it might just have the ppc version, in which case it will probably say "/bin/ps: setuid Mach-O executable ppc"
Not saying these things would indicate that the file has gotten messed up somehow (hard disk problems? It might be worth systematically testing everything in /bin?)
posted by advil at 2:20 PM on September 19, 2006
/bin/ps: setuid Mach-O universal binary with 2 architectures
/bin/ps (for architecture i386): Mach-O executable i386
/bin/ps (for architecture ppc): Mach-O executable ppc
if you have 10.4.7, or it might just have the ppc version, in which case it will probably say "/bin/ps: setuid Mach-O executable ppc"
Not saying these things would indicate that the file has gotten messed up somehow (hard disk problems? It might be worth systematically testing everything in /bin?)
posted by advil at 2:20 PM on September 19, 2006
ok, so the file is most definitely corrupted somehow. I'm afraid pmbuko's suggestion is all I can think of right now -- but I'd personally be worried about hard drive problems, because I don't see any other way for files in /bin to get changed on their own. I've got to go, good luck!
posted by advil at 2:23 PM on September 19, 2006
posted by advil at 2:23 PM on September 19, 2006
Response by poster: Guys, thanks for the idea of replacing the file. ps seems to be working
[jasmeet@Argentum jasmeet] > file /bin/ps
/bin/ps: Mach-O executable ppc
Advil, I am concerned with the whole 'hard drive problems' that you mentioned. Do you mean, the drive specifically, or the OS X install?
This has happened twice now, so I'm really concerned, and as much of a pain it would be to reinstall, it's not impossible.
posted by jasmeet at 2:31 PM on September 19, 2006
[jasmeet@Argentum jasmeet] > file /bin/ps
/bin/ps: Mach-O executable ppc
Advil, I am concerned with the whole 'hard drive problems' that you mentioned. Do you mean, the drive specifically, or the OS X install?
This has happened twice now, so I'm really concerned, and as much of a pain it would be to reinstall, it's not impossible.
posted by jasmeet at 2:31 PM on September 19, 2006
Response by poster: A buddy of mine asked me to see if there was a way to find out if I've been rootkit'ed, since only root has the ability to mess up anything in /bin (and I've done nothing of that sort). Is there a way to tell?
posted by jasmeet at 2:37 PM on September 19, 2006
posted by jasmeet at 2:37 PM on September 19, 2006
Not really, unless you start to notice something else interesting that's going on -- i.e. do you have a bunch of processes running in your process list that you didn't have before? That'd be a clue.
My suspicion would be more along the lines of hard drive corruption.
posted by SpecialK at 3:16 PM on September 19, 2006
My suspicion would be more along the lines of hard drive corruption.
posted by SpecialK at 3:16 PM on September 19, 2006
Response by poster: As in, my physical drive is going out? Or just my OS X Install?
posted by jasmeet at 3:32 PM on September 19, 2006
posted by jasmeet at 3:32 PM on September 19, 2006
The same file getting corrupted twice doesn't sound like a physical problem with the drive (especially if you've not noticed other files getting corrupted). /bin/ps is probably one of the first files to get laid down on the disk when it was clean and new; when you overwrote it with a new copy, I don't believe there's any reason Mac OS X would have put the new file at the same physical location on the disk; in fact, just the opposite. I'm not an HFS+ guru, though, so I could be mistaken.
Sounds like some piece of software on the system... one that's running with administrator permissions, since normal users can't write to files in /bin.
posted by BaxterG4 at 4:41 PM on September 19, 2006
Sounds like some piece of software on the system... one that's running with administrator permissions, since normal users can't write to files in /bin.
posted by BaxterG4 at 4:41 PM on September 19, 2006
It is extremely common for rootkits to replace ps with their own version of ps which does not show rootkit processes running, even when they are.
The fact that ps has stopped working twice for you should be a BIG RED FLAG. I would assume that some foreign software on your machine is replacing ps with a hacked version (which happens not to work at all - stupid hackers), and proceed from there.
posted by jellicle at 5:03 PM on September 19, 2006 [1 favorite]
The fact that ps has stopped working twice for you should be a BIG RED FLAG. I would assume that some foreign software on your machine is replacing ps with a hacked version (which happens not to work at all - stupid hackers), and proceed from there.
posted by jellicle at 5:03 PM on September 19, 2006 [1 favorite]
Advil, I am concerned with the whole 'hard drive problems' that you mentioned. Do you mean, the drive specifically, or the OS X install?
I was thinking that the hard drive was on its way out and had some kind of physical problem. But I agree with the others that it's extremely unlikely that this would happen to /bin/ps twice if this were so (or you'd be seeing errors all over the place). At that point I'm really out of my depth. One idea that comes to mind, though, which relies on the assumption that the rootkit has replaced other files, and that they don't work either, would be to type something like "for a in /bin/*; do file $a; done" (requires bash, not csh). Try /sbin as well. There are some programs that attempt to detect rootkits in a more systematic manner, but I don't know much about them. The wikipedia entry on rootkits references a few.
If you really have a rootkit, the odds are you are going to have to reinstall everything.
posted by advil at 5:47 PM on September 19, 2006
I was thinking that the hard drive was on its way out and had some kind of physical problem. But I agree with the others that it's extremely unlikely that this would happen to /bin/ps twice if this were so (or you'd be seeing errors all over the place). At that point I'm really out of my depth. One idea that comes to mind, though, which relies on the assumption that the rootkit has replaced other files, and that they don't work either, would be to type something like "for a in /bin/*; do file $a; done" (requires bash, not csh). Try /sbin as well. There are some programs that attempt to detect rootkits in a more systematic manner, but I don't know much about them. The wikipedia entry on rootkits references a few.
If you really have a rootkit, the odds are you are going to have to reinstall everything.
posted by advil at 5:47 PM on September 19, 2006
Response by poster: Apologies ahead for what might seem like a flood:
/bin/[: Mach-O executable ppc
/bin/bash: Mach-O executable ppc
/bin/cat: Mach-O executable ppc
/bin/chmod: Mach-O executable ppc
/bin/cp: Mach-O executable ppc
/bin/csh: Mach-O executable ppc
/bin/date: Mach-O executable ppc
/bin/dd: Mach-O executable ppc
/bin/df: setgid Mach-O executable ppc
/bin/domainname: Mach-O executable ppc
/bin/echo: Mach-O executable ppc
/bin/ed: Mach-O executable ppc
/bin/expr: Mach-O executable ppc
/bin/hostname: Mach-O executable ppc
/bin/kill: Mach-O executable ppc
/bin/ksh: Mach-O executable ppc
/bin/launchctl: Mach-O executable ppc
/bin/link: Mach-O executable ppc
/bin/ln: Mach-O executable ppc
/bin/ls: Mach-O executable ppc
/bin/mkdir: Mach-O executable ppc
/bin/mv: Mach-O executable ppc
/bin/pax: Mach-O executable ppc
/bin/ps: Mach-O executable ppc
/bin/pwd: Mach-O executable ppc
/bin/rcp: setuid Mach-O executable ppc
/bin/rm: Mach-O executable ppc
/bin/rmdir: Mach-O executable ppc
/bin/sh: Mach-O executable ppc
/bin/sleep: Mach-O executable ppc
/bin/stty: Mach-O executable ppc
/bin/sync: Mach-O executable ppc
/bin/tcsh: Mach-O executable ppc
/bin/test: Mach-O executable ppc
/bin/unlink: Mach-O executable ppc
/bin/wait4path: Mach-O executable ppc
/bin/zsh: Mach-O executable ppc
/bin/zsh-4.2.3: Mach-O executable ppc
Looks normal here (the ps has been replaced, and I'm working on running chrootkit. Seems every time I click on the executable icon, finder crashes.
I did run it under Terminal, with the exception of some errors, every thing seemed ok:
Checking `sshd'... /usr/bin/strings: can't map file: / ((os/kern) invalid argument)
not infected
Checking `aliens'... find: /dev/fd/3: Bad file descriptor
Searching for suspicious files and dirs, it may take a while...
/usr/lib/php/.filemap /usr/lib/php/.registry
/usr/lib/php/.registry
Checking `lkm'... chkproc: not tested
Checking `sniffer'... not tested: can't exec ./ifpromisc
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp
I truncated the results (most stated either not found, or not infected) but I'm going to try recompiling the app again.
posted by jasmeet at 6:54 PM on September 19, 2006
/bin/[: Mach-O executable ppc
/bin/bash: Mach-O executable ppc
/bin/cat: Mach-O executable ppc
/bin/chmod: Mach-O executable ppc
/bin/cp: Mach-O executable ppc
/bin/csh: Mach-O executable ppc
/bin/date: Mach-O executable ppc
/bin/dd: Mach-O executable ppc
/bin/df: setgid Mach-O executable ppc
/bin/domainname: Mach-O executable ppc
/bin/echo: Mach-O executable ppc
/bin/ed: Mach-O executable ppc
/bin/expr: Mach-O executable ppc
/bin/hostname: Mach-O executable ppc
/bin/kill: Mach-O executable ppc
/bin/ksh: Mach-O executable ppc
/bin/launchctl: Mach-O executable ppc
/bin/link: Mach-O executable ppc
/bin/ln: Mach-O executable ppc
/bin/ls: Mach-O executable ppc
/bin/mkdir: Mach-O executable ppc
/bin/mv: Mach-O executable ppc
/bin/pax: Mach-O executable ppc
/bin/ps: Mach-O executable ppc
/bin/pwd: Mach-O executable ppc
/bin/rcp: setuid Mach-O executable ppc
/bin/rm: Mach-O executable ppc
/bin/rmdir: Mach-O executable ppc
/bin/sh: Mach-O executable ppc
/bin/sleep: Mach-O executable ppc
/bin/stty: Mach-O executable ppc
/bin/sync: Mach-O executable ppc
/bin/tcsh: Mach-O executable ppc
/bin/test: Mach-O executable ppc
/bin/unlink: Mach-O executable ppc
/bin/wait4path: Mach-O executable ppc
/bin/zsh: Mach-O executable ppc
/bin/zsh-4.2.3: Mach-O executable ppc
Looks normal here (the ps has been replaced, and I'm working on running chrootkit. Seems every time I click on the executable icon, finder crashes.
I did run it under Terminal, with the exception of some errors, every thing seemed ok:
Checking `sshd'... /usr/bin/strings: can't map file: / ((os/kern) invalid argument)
not infected
Checking `aliens'... find: /dev/fd/3: Bad file descriptor
Searching for suspicious files and dirs, it may take a while...
/usr/lib/php/.filemap /usr/lib/php/.registry
/usr/lib/php/.registry
Checking `lkm'... chkproc: not tested
Checking `sniffer'... not tested: can't exec ./ifpromisc
Checking `wted'... not tested: can't exec ./chkwtmp
Checking `z2'... not tested: can't exec ./chklastlog
Checking `chkutmp'... not tested: can't exec ./chkutmp
I truncated the results (most stated either not found, or not infected) but I'm going to try recompiling the app again.
posted by jasmeet at 6:54 PM on September 19, 2006
This thread is closed to new comments.
posted by pmbuko at 2:01 PM on September 19, 2006