MonitorControl: Ventura System Settings processes sometimes do not close if MonitorControl is running
Before opening the issue, have you…?
- Searched for existing issues
- Looked through the wiki
- Updated MonitorControl to the latest version (if applicable)
Describe the bug
This is a strange one. I noticed that the various System Settings processes in Ventura (13.0.1) will sometimes stay running even after System Settings is closed. Quitting MonitorControl frees them up. This also seems related to sleep behavior (to be described in repro steps).
Steps to reproduce
- Open the System Settings app.
- Check Activity Monitor for all the various processes that are open: Wallpaper (System Settings), Displays (System Settings), etc.
- Put the Mac to sleep with System Settings still open.
- Wake up the Mac.
- Quit System Settings.
- Note that all the (System Settings) processes are still running.
- Quit MonitorControl
- Note that all the (System Settings) processes close instantly.
Expected behavior
Having MonitorControl open should not block (System Settings) processes from ending. Some of them can use a fair amount of RAM if you mess around with them.
Anything else?
Reproducing the bug video: https://www.youtube.com/watch?v=YKscEk2MJj8
Environment Information (please complete the following information)
- macOS version: 13.0.1 Ventura
- Mac model: MacBook Pro, 13-inch, M1, 2020
- MonitorControl version: 4.1.0 Build 7034
- Monitor(s): Dell U2723QE
- Apple Silicon/M1 (yes or no): yes
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 17 (8 by maintainers)
I wrote a tool that fixed this kind of issues. You can download it here.
https://github.com/owenzhao/App-Helper
Just did some checking, BetterDisplay does not seem to produce this, but I was able to reproduce it with MonitorControl at my end as well. Sad news is I have no idea at all why this happens.
A theory is that DisplayBuddy (which is an app I am not affiliated with) might have this issue because it might have… hmm… reused some of the… ideas in MonitorControl so faithfully that including some of the bugs as well? (Not that there is anything wrong with that as MC is MIT licensed 😃). On the other hand BetterDisplay is a major reimplementation from ground-up so probably by accident I just skipped the same pitfall, even though it uses a many of the same technologies as MC.
I’ll try to look into it whenever I can get to it. Meanwhile you can use BetterDisplay if this issue bothers you as a workaround (note that MC and BD functionalities do not fully overlap - BD has a huge amount of stuff not found in MC, while MC does some things that BD still lacks or supports in a more complicated manner).