Thanks for being a part of WWDC25!

How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here

Service Showing "Not Responding" in Activity Monitor Despite Running Threads.

I am encountering an issue with my application, BloxOneEndpoint.pkg, which includes two services:

rc_service_infoblox – Runs as the root user. Controller Application – Runs as a normal user. Although a thread within rc_service_infoblox is running fine and performing its expected tasks, I notice that the service appears as "Not Responding" in Activity Monitor. Despite normal functionality, this status is concerning, as it may indicate some issue to customer.

I would appreciate any insights into why this might be happening and how to resolve it. Is there a specific API or mechanism I should use to ensure the service remains in a "Running" state in Activity Monitor?

Thank you for your guidance.

Answered by DTS Engineer in 834136022

Sorry about the delay. I missed your earlier reply for some reason.

rc_service_infoblox is launched using launchd via a launch daemon.

OK. In that case it really shouldn’t be connecting to the window server. For more background on this whole problem, see TN2083 Daemons and Agents.

What frameworks does rc_service_infoblox link with? You can get the list using otool:

% otool -L /path/to/rc_service_infoblox

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Activity Monitor shows (Not Responding) when the process is connected to the window server and isn’t handling window server events. If rc_service_infoblox is running as root, it shouldn’t be connecting to the window server, and thus you should never see this flag.

How is rc_service_infoblox being launched?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for your response!

rc_service_infoblox is launched using launchd via a launch daemon.

We implement a message queue communication system between our controller application and rc_service_infoblox to monitor status. The controller checks the service status by posting messages to this queue, and rc_service_infoblox responds with status updates when it receives these messages.

Interestingly, this "Not Responding" issue occurs most frequently when the system wakes from sleep. The service continues to function normally despite showing this status in Activity Monitor.

Accepted Answer

Thank you for your response!

rc_service_infoblox is launched using launchd via a launch daemon.

We implement a message queue communication system between our controller application and rc_service_infoblox to monitor status. The controller checks the service status by posting messages to this queue, and rc_service_infoblox responds with status updates when it receives these messages.

Interestingly, this "Not Responding" issue occurs most frequently when the system wakes from sleep. The service continues to function normally despite showing this status in Activity Monitor.

Any update on the above query?

Sorry about the delay. I missed your earlier reply for some reason.

rc_service_infoblox is launched using launchd via a launch daemon.

OK. In that case it really shouldn’t be connecting to the window server. For more background on this whole problem, see TN2083 Daemons and Agents.

What frameworks does rc_service_infoblox link with? You can get the list using otool:

% otool -L /path/to/rc_service_infoblox

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Here is the output of otool

/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture x86_64):
	@executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2299.50.120)
	/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture arm64):
	@executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2299.50.120)
	/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
Here is the output of otool

Thanks.

Note that you’re linking to AppKit. Why?

AppKit is the canonical example of a framework that’s not daemon safe, per the definition in TN2083 Daemons and Agents. Your daemon shouldn’t be linking to it. If it does, it will run into problems at some point. This ‘not responding’ issue is a relatively minor problem, but there’s the potential for much worse problems.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Even after removing link to AppKit I see the app going to Not Responding state.

Here is the otool output

╰─ otool -L /Applications/Infoblox/BloxOne\ Endpoint.app/Contents/MacOS/infoblox_rc_service ─╯ /Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture x86_64): @executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0) @executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0) /Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture arm64): @executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0) @executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)

Can you post that output as a code block. It’s quite hard to read as it. See tip 5 in Quinn’s Top Ten DevForums Tips for advice on how to do that.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture x86_64):
	@executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/infoblox_rc_service (architecture arm64):
	@executable_path/libcurl.dylib (compatibility version 1.0.0, current version 1.0.0)
	@executable_path/libcares.dylib (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 1406.0.4)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1241.100.11)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 60420.101.2)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1971.0.0)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1500.65.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)

Interesting. All of those libraries are reasonable to use in a daemon.

Does your daemon dynamically load plug-in code into its process? If so, you should run this otool test over those plug-ins as well.

If not, debugging this gets trickier )-:

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry for delayed reply. We are using a CoreDNS plugin in our application. I checked the binary using otool, and I don't see it linking against AppKit.

Here’s the otool -L output for our coredns binary:

─    ~/B1E/VirtualBucket_atcapi/VB_7Jan/atc.api.service    vb_latest ················································································································ ✔  07:45:57 PM  ─╮
╰─ otool -L /Applications/Infoblox/BloxOne\ Endpoint.app/Contents/MacOS/coredns                                                                                                                                  ─╯
/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/coredns (architecture x86_64):
	/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)
/Applications/Infoblox/BloxOne Endpoint.app/Contents/MacOS/coredns (architecture arm64):
	/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 0.0.0, current version 0.0.0)

As you can see, AppKit is not listed among the linked frameworks.

At this point, I am unsure how to proceed with debugging this issue.

Bah, I was hoping we could debug this with static analysis. Sadly, that doesn’t seem to be the case.

One thing that might help here is to set a symbolic breakpoint on INIT_Processes. If you do that and then run your program, does it stop at the breakpoint? If so, what does the backtrace look like?

For example, here’s what I see when I start a standard app with that breakpoint:

% lldb Test777284.app/Contents/MacOS/Test777284
(lldb) target create "Test777284.app/Contents/MacOS/Test777284"
…
(lldb) br set -n INIT_Processes
Breakpoint 1: where = HIServices`INIT_Processes(), address = 0x0000000186fe371c
(lldb) r
…
Process 28979 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x000000018c45371c HIServices`INIT_Processes()
HIServices`INIT_Processes:
->  0x18c45371c <+0>:  pacibsp 
    0x18c453720 <+4>:  stp    x20, x19, [sp, #-0x20]!
    0x18c453724 <+8>:  stp    x29, x30, [sp, #0x10]
    0x18c453728 <+12>: add    x29, sp, #0x10
Target 0: (Test777284) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x000000018c45371c HIServices`INIT_Processes()
    frame #1: 0x000000018c4536e8 HIServices`GetCurrentProcess + 36
    frame #2: 0x000000018a3d00ac AppKit`-[NSMenuBarPresentationInstance _getAggregateUIMode:withOptions:] + 148
    …
    frame #9: 0x00000001895e716c AppKit`NSApplicationMain + 384
    frame #12: 0x0000000100001b08 Test777284`main at <compiler-generated>:0
    frame #13: 0x0000000185542b4c dyld`start + 6000

Now, I’m going this from Terminal, which is fine in my case because I’m working with an app. You’re working with a daemon, which isn’t something you should run from Terminal in general. If your daemon won’t work from Terminal at all, you can do the following:

  1. Modify your daemon so that it waits for the debugger at the start of main. I usually do this by logging to the system log [1] and then calling pause.

  2. Start your daemon using sudo launchctl start JOB_LABEL.

  3. Check to see if it’s already visible in Activity Monitor. If it is, something before main has connected to the window server, which makes things substantially harder )-: Lemme know in that case and I’ll think about this some more.

  4. If not, attach with LLDB.

  5. Then set the INIT_Processes breakpoint.

  6. And continue.


Oh, there’s one other bit of info I’d like from you. If you reproduce the problem normally — without any of the stuff I’ve talked about above — and then attach with LLDB and run image list, what do you get back?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] See Your Friend the System Log.

Service Showing "Not Responding" in Activity Monitor Despite Running Threads.
 
 
Q