rpcsvchost using 99% CPU !!

[the bug]

On my mid 2010 Mac Mini running 10.9.5 I noticed that every time I cold boot it the process "rpcsvchost" is using 99% of the CPU in activity monitor.

Most times rebooting takes care of it, until it sits powered off overnight, then on the first boot up it is back to eating 99% again.

I have reset SMC and PRAM, turned off all unnecessary items but it still continues.

I've searched online and found a few others that have had the same problem, but haven't found any answers.

Any advice would be appreciated, since I think my next step may be re-loading Mavericks.

Thanks in advance for any help.

- Jay

 

[the bug]

Wow, almost 100 views and nobody else has seen this.
Here's a little more info :
I reinstalled Mavericks last night and it seemed better after a couple of reboots, then today rpcsvchost was back up to using 99%.
It's running as root, so I don't think it's a startup item from any particular account.

Only a couple of entries in the console about it, I will post those and a spindump log below.

Very strange that it is only after it has been sitting off for a while.

- Jay

_____________________

9/25/14 6:31:25.000 PM kernel[0]: process rpcsvchost[89] thread 692 caught burning CPU! It used more than 50% CPU (Actual recent usage: 62%) over 180 seconds. thread lifetime cpu usage 90.015346 seconds, (71.342635 user, 18.672711 system) ledger info: balance: 90007778831 credit: 90007778831 debit: 0 limit: 90000000000 (50%) period: 180000000000 time since last refill (ns): 143033006696

______________________________________________________

9/25/14 6:31:28.915 PM spindump[290]: Saved cpu_resource.spin report for rpcsvchost version ??? (???) to /Library/Logs/DiagnosticReports/rpcsvchost_2014-09-25-183128_UpstairsMini.cpu_resource.spin

_______________________________________________________

Date/Time: 2014-09-25 18:28:59 -0400
OS Version: 10.9.5 (Build 13F34)
Architecture: x86_64
Report Version: 18

Command: rpcsvchost
Path: /usr/libexec/rpcsvchost
Version: ??? (???)
Parent: launchd [1]

PID: 89
Event: cpu usage (microstackshots only)
Thread: 0x2b4 (62% cpu over 146 seconds)
Duration: 146.00s
Steps: 98

Hardware model: Macmini4,1
Active cpus: 2
Fan speed: 1800 rpm


Powerstats for: rpcsvchost [89] thread 0x2b4
Start time: 2014-09-25 18:29:54 -0400
End time: 2014-09-25 18:31:25 -0400
Parent: launchd
Microstackshots: 76 samples (77%)
Primary state: 59 samples Non-Frontmost App, Non-Background Priority, User mode
User Activity: 0 samples Idle, 76 samples Active
Power Source: 0 samples on Battery, 76 samples on AC
76 thread_start + 13 (libsystem_pthread.dylib) [0x7fff90865fc9]
76 _pthread_start + 137 (libsystem_pthread.dylib) [0x7fff9086172a]
76 _pthread_body + 138 (libsystem_pthread.dylib) [0x7fff90861899]
76 proxy_start + 57 (DCERPC) [0x10782baa1]
67 timer_loop + 239 (DCERPC) [0x10785b439]
65 dcethread_cond_timedwait_throw + 11 (DCERPC) [0x10782d4f7]
31 dcethread_cond_timedwait + 111 (DCERPC) [0x10782d496]
28 __gettimeofday + 10 (libsystem_kernel.dylib) [0x7fff852e11cb]
17 <Kernel mode>
2 _pthread_cond_wait + 142 (libsystem_pthread.dylib) [0x7fff908639f2]
1 _pthread_testcancel + 56 (libsystem_pthread.dylib) [0x7fff90862929]
1 DYLD-STUB$$OSSpinLockLock + 6 (libsystem_pthread.dylib) [0x7fff9086610a]
1 _pthread_cond_wait + 154 (libsystem_pthread.dylib) [0x7fff908639fe]
15 dcethread_cond_timedwait + 85 (DCERPC) [0x10782d47c]
6 dcethread__begin_block + 149 (DCERPC) [0x10782d073]
5 dcethread__unlock + 32 (DCERPC) [0x10782cbfe]
5 pthread_mutex_unlock + 60 (libsystem_pthread.dylib) [0x7fff908648f3]
2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
2 __mtx_droplock + 590 (libsystem_pthread.dylib) [0x7fff9086450c]
1 __mtx_droplock + 615 (libsystem_pthread.dylib) [0x7fff90864525]
1 dcethread__debug_set_callback + 20 (DCERPC) [0x10782c0b5]
5 dcethread__begin_block + 141 (DCERPC) [0x10782d06b]
1 _pthread_cond_signal + 144 (libsystem_pthread.dylib) [0x7fff9086374a]
1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
1 _pthread_cond_signal + 39 (libsystem_pthread.dylib) [0x7fff908636e1]
1 _pthread_cond_check_init + 6 (libsystem_pthread.dylib) [0x7fff90863ce9]
1 _pthread_cond_signal + 52 (libsystem_pthread.dylib) [0x7fff908636ee]
1 _pthread_cond_signal + 227 (libsystem_pthread.dylib) [0x7fff9086379d]
4 dcethread__begin_block + 38 (DCERPC) [0x10782d004]
3 dcethread__lock + 18 (DCERPC) [0x10782cb05]
1 _pthread_mutex_lock + 565 (libsystem_pthread.dylib) [0x7fff9086483a]
1 pthread_mutex_unlock + 223 (libsystem_pthread.dylib) [0x7fff90864996]
1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
1 dcethread__lock + 89 (DCERPC) [0x10782cb4c]
13 dcethread_cond_timedwait + 144 (DCERPC) [0x10782d4b7]
6 dcethread__end_block + 28 (DCERPC) [0x10782d12c]
4 dcethread__lock + 18 (DCERPC) [0x10782cb05]
2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
1 _pthread_mutex_lock + 229 (libsystem_pthread.dylib) [0x7fff908646ea]
1 _pthread_mutex_lock + 51 (libsystem_pthread.dylib) [0x7fff90864638]
1 pthread_threadid_np + 30 (libsystem_pthread.dylib) [0x7fff90861b43]
1 dcethread__lock + 53 (DCERPC) [0x10782cb28]
1 dcethread__lock + 65 (DCERPC) [0x10782cb34]
1 dcethread__sanity + 112 (DCERPC) [0x10782cd25]
4 dcethread__end_block + 96 (DCERPC) [0x10782d170]
3 dcethread__unlock + 32 (DCERPC) [0x10782cbfe]
1 pthread_mutex_unlock + 217 (libsystem_pthread.dylib) [0x7fff90864990]
1 pthread_mutex_unlock + 75 (libsystem_pthread.dylib) [0x7fff90864902]
1 pthread_mutex_unlock + 60 (libsystem_pthread.dylib) [0x7fff908648f3]
1 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
1 dcethread__unlock + 15 (DCERPC) [0x10782cbed]
1 dcethread__sanity + 101 (DCERPC) [0x10782cd1a]
2 dcethread__end_block + 88 (DCERPC) [0x10782d168]
2 OSAtomicCompareAndSwapLong$VARIANT$mp + 8 (libsystem_platform.dylib) [0x7fff8b640bd4]
1 dcethread__init_self + 75 (DCERPC) [0x10782caf3]
3 dcethread_cond_timedwait + 59 (DCERPC) [0x10782d462]
2 dcethread__self + 25 (DCERPC) [0x10782ca64]
1 pthread_once + 87 (libsystem_pthread.dylib) [0x7fff90862893]
1 dcethread__self + 37 (DCERPC) [0x10782ca70]
2 dcethread__new + 145 (DCERPC) [0x10782ca4b]
1 dcethread_cond_timedwait + 114 (DCERPC) [0x10782d499]
1 dcethread_cond_timedwait_throw + 37 (DCERPC) [0x10782d511]
1 mach_thread_self + 5 (libsystem_kernel.dylib) [0x7fff852de15f]
5 timer_loop + 73 (DCERPC) [0x10785b393]
5 rpc__clock_update + 33 (DCERPC) [0x10785a6df]
4 ??? [0]
3 __commpage_gettimeofday + 41 (libsystem_kernel.dylib) [0x7fff852ddbd9]
2 mach_absolute_time + 26 (libsystem_kernel.dylib) [0x7fff852dcca6]
1 mach_absolute_time + 28 (libsystem_kernel.dylib) [0x7fff852dcca8]
1 __commpage_gettimeofday + 83 (libsystem_kernel.dylib) [0x7fff852ddc03]
1 gettimeofday + 6 (libsystem_c.dylib) [0x7fff851051a9]
2 timer_loop + 78 (DCERPC) [0x10785b398]
2 rpc__timer_callout + 228 (DCERPC) [0x10785b87f]
2 timer_loop + 246 (DCERPC) [0x10785b440]

 

[the bug]

I am starting to wonder if this may have something to do with the PRAM battery.

I see a bunch of references to setting the time from the Apple server in the spindump log, but I never lose the startup disk selection in the control panel, which I thought that was another symptom of a dead battery.

I'm also suspecting battery since my son just came in, and told me not to kill the light switch while the mini is running, since he had to move the plug to the same outlet the light switch controls.

So for the last few weeks (AFIK) the mini has had the mains disconnected all day, since the light switch stays off all day, DOH !

I plugged it into a non switched outlet for tonight and will try it again tomorrow.

Hopefully if it is the battery it's not too far gone, since it looks like a bitch to replace it in one of these unibody mini's.
I installed an SSD in my other mini, and still have nightmares about it from time to time .

If anyone has any other suggestions to check in the meantime, it would be appreciated, since I won't know if it's the battery or not until tomorrow, thanks.

- Jay

 

[satcomer]

Did you check /Applications/Utilities/Activity Viewer.app to quit the run away service? Did you run that link free application EtreCheck and see if that service needs updating or deletion?

 

[the bug]

Did you check /Applications/Utilities/Activity Viewer.app to quit the run away service? Did you run that link free application EtreCheck and see if that service needs updating or deletion?

Thanks for the reply satcomer,
I am able to quit the process in Activity Monitor, and it stays gone until the machine sits unplugged for a few hours, then it was coming back.
I did use EtreCheck, and no 3rd party daemons or outdated stuff to speak of.

I'm thinking it is the PRAM battery on it's way out, since I haven't had the problem at all today after it was plugged in overnight.

I think the problem was that my son switched the AC power cord to an outlet that stays switched off most of the time, and that was killing an already weak battery.

I have never seen a PRAM battery cause a system to slow down before, so that's a new one on me.

Hopefully it will charge back up and be alright, since like I said before, it looks like a bear to get to the battery.

Thanks again for the reply, I will be keeping an eye on it, but hopefully it is good now.

Thanks.

- Jay

 

[chown33]

Hopefully it will charge back up and be alright, since like I said before, it looks like a bear to get to the battery.

Thanks again for the reply, I will be keeping an eye on it, but hopefully it is good now.

Thanks.

- Jay

I don't think the Mini's PRAM battery is rechargeable. Per this photo, it's a 2032-type coin cell (3V), which are not rechargeable in general:

What's happening now is that the PRAM is being powered by the trickle (low-current) supply. When you unplug it or switch the outlet off, the weak/dead battery takes over, which is when it fails. It could keep working for any number of minutes after power loss, but still be essentially a dead parrot battery.

FWIW, the clock is probably going to be the first thing to fail, since it has to keep counting. The setting of the startup disk is static (doesn't change while power is removed). As low-power SRAM, a static values is easy to maintain, or as EEPROM it can be maintained with no battery at all. Offhand I don't know how the static storage cells are implemented (SRAM or EEPROM), but the clock is almost certainly not EEPROM (it'd wear out too quickly).

 

[satcomer]

Here are some Apple Support Documents:

OS X Mavericks: Reset your computer’s PRAM

Intel-based Macs: Resetting the System Management Controller (SMC)

 

[VaZ]

I have the exact same problem but with Mojave and Macbookpro6,2 - Does this have an internal pram battery?