Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Disable Universal Control?
- Thread starter amok-san
- Start date
- Sort by reaction score
Can you please clarify what process are you referring to? I have Monterey in a virtual machine and I don’t see it.
With SIP disabled, many system processes can be prevented from starting.
The process is called "Universelle Steuerung" which has to be "Universal Control".
"launchctl list" lists it as "com.apple.ensemble".
there is an "Ensemble.plist" in /Library/Preferences/FeatureFlags/Domain/Ensemble.plist where I could set "enabled" to "false" but I have no write access for the system files (SIP disabled).
On a clean install the process was not there, only after migrating my data. Universal Control and Handoff are disabled.
"launchctl list" lists it as "com.apple.ensemble".
there is an "Ensemble.plist" in /Library/Preferences/FeatureFlags/Domain/Ensemble.plist where I could set "enabled" to "false" but I have no write access for the system files (SIP disabled).
On a clean install the process was not there, only after migrating my data. Universal Control and Handoff are disabled.
The launch agent is /System/Library/LaunchAgents/com.apple.ensemble.plist
To stop it for the main admin user (501)
to disable it from starting again
I’ve tested with SIP disabled (csrutil disable from Terminal in Recovery), but it might work with SIP enabled as well.
To reverse the modifications
To stop it for the main admin user (501)
Code:
launchctl bootout gui/501/com.apple.ensembleto disable it from starting again
Code:
launchctl disable gui/501/com.apple.ensembleI’ve tested with SIP disabled (csrutil disable from Terminal in Recovery), but it might work with SIP enabled as well.
To reverse the modifications
Code:
launchctl enable gui/501/com.apple.ensemble
launchctl kickstart gui/501/com.apple.ensemble
Any clue as to why the bootout command returns "Boot-out failed: 150: Unknown error: 150"? Do you need to have SIP disabled to be able to disable it? macOS doesn't seem to let me stop that process in any way.
I get the same error with SIP enabled, but you can suspend the process with
Code:
launchctl kickstart -ks gui/501/com.apple.ensemble
Code:
killall UniversalControlThank you! Those are actually quite interesting commands, I need to dig deeper into the new launchctl syntax.
However, what happens that way, is that it's killed then automatically restarted. I will need to try out some more things.
Could be a coincidence. Reinstall the OS and don't automatically migrate your data.
Which process is running your CPU? The identifiable UC processes are using minimal resources on my MBP. What happens if you just kill the processes in Activity Monitor? Do they start again and use the same resources (did you turn off 'automatically reconnect to Mac or ipad' in the UC prefs before turning UC off)?
Hi amok-san and darngooddesign,
Just to let you know ... I've sent a bug report to Apple concerning the following scenario that perhaps may be the reason why you are seeing significant resources being consumed by UC.
I began by using UC on three MBPs, an M1, an M1 Max, and an i9. I then returned to an office with two of those computers that was roughly 75 feet horizontally away, one floor up, and probably four walls between the first location and the office; that is to say, one of the three MBPs was 75 feet, 4 walls, and 1 floor away from the other two MBPs. When I attempted to use UC to connect the two local MBPs, I found UC would not work between the two local MBPs even though the third distant MBP was not seen by the two local MBPs. Also, UC was now chewing up 100% of a single CPU on both local machines even though it would not connect those two MBPs. All three MBPs, however, were still connected to the same WiFi LAN, but the two local machines were out of Bluetooth range of the third distant machine.
I tried killing UC processes, using launchctl to switch UC on and off, rebooting, etc. but nothing worked. Finally I came to the following conclusion:
It turns out that even though they were out of BT range and the two local MBPs could not "see" (by UC nor display sharing) the third distant MBP, UC was expending 100% CPU time on the two local MBPs attempting to connect to the distant third MBP even though it was out-of-range. I had to go back to the distant MBP and switch off its UC (System Preferences -> Displays -> Universal Control... -> (uncheck) Allow your cursor...) and this allowed the other two local MBPs to reconnect via UC. An error message informing me that this was the problem would have been nice, but there was no indication of what the trouble was.
Solouki
I wish there was an easier way to do this. On Sequoia I have disabled Universal Control in Settings, but the process is still using the CPU.