[GH-ISSUE #1221] Ventura System Settings processes sometimes do not close if MonitorControl is running #710

Closed
opened 2026-05-05 06:33:45 -06:00 by gitea-mirror · 17 comments
Owner

Originally created by @hsugene on GitHub (Nov 10, 2022).
Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1221

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

  1. Open the System Settings app.
  2. Check Activity Monitor for all the various processes that are open: Wallpaper (System Settings), Displays (System Settings), etc.
  3. Put the Mac to sleep with System Settings still open.
  4. Wake up the Mac.
  5. Quit System Settings.
  6. Note that all the (System Settings) processes are still running.
  7. Quit MonitorControl
  8. 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
Originally created by @hsugene on GitHub (Nov 10, 2022). Original GitHub issue: https://github.com/MonitorControl/MonitorControl/issues/1221 ### Before opening the issue, have you...? - [X] Searched for existing issues - [X] Looked through [the wiki](https://github.com/MonitorControl/MonitorControl/wiki) - [X] 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 1. Open the System Settings app. 2. Check Activity Monitor for all the various processes that are open: Wallpaper (System Settings), Displays (System Settings), etc. 3. Put the Mac to sleep with System Settings still open. 4. Wake up the Mac. 5. Quit System Settings. 6. Note that all the (System Settings) processes are still running. 7. Quit MonitorControl 8. 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) ```markdown - 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 ```
gitea-mirror 2026-05-05 06:33:45 -06:00
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

This is an interesting one! I cannot seem to be able to reproduce it (same OS, M1 MBP 14") though. Is putting the mac to sleep a required step to reproduce what happens (tried without it)? Do you have all accessibility settings enabled? It might be that this is what keeps system settings open (as MC checks accessibility status), but it is just a hunch.

<!-- gh-comment-id:1313385355 --> @waydabber commented on GitHub (Nov 14, 2022): This is an interesting one! I cannot seem to be able to reproduce it (same OS, M1 MBP 14") though. Is putting the mac to sleep a required step to reproduce what happens (tried without it)? Do you have all accessibility settings enabled? It might be that this is what keeps system settings open (as MC checks accessibility status), but it is just a hunch.
Author
Owner

@x-magic commented on GitHub (Nov 14, 2022):

I can reproduce this as well. (MBA M2)

Procedures:

  • Open Activity Monitor, filter by "System settings"
  • Open System settings, a bunch of processes show up in activity monitor
  • Sleep
  • Wake up, quit system settings, processes remain in activity monitor
  • Quit MonitorControl, all processes disappear
    Bonus:
  • Reopen MonitorControl, then open System Settings, processes show up in activity monitor again
  • Quit System settings without sleep, all processes disappear normally

I always quit system pref/settings after use so that's a surprise to me haha. I wonder how it looks in older version of macOS.

<!-- gh-comment-id:1313458336 --> @x-magic commented on GitHub (Nov 14, 2022): I can reproduce this as well. (MBA M2) Procedures: - Open Activity Monitor, filter by "System settings" - Open System settings, a bunch of processes show up in activity monitor - Sleep - Wake up, quit system settings, processes remain in activity monitor - Quit MonitorControl, all processes disappear Bonus: - Reopen MonitorControl, then open System Settings, processes show up in activity monitor again - Quit System settings without sleep, all processes disappear normally I always quit system pref/settings after use so that's a surprise to me haha. I wonder how it looks in older version of macOS.
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

Ok, so sleep has something to do with the problem then. Nice! :)

<!-- gh-comment-id:1313461168 --> @waydabber commented on GitHub (Nov 14, 2022): Ok, so sleep has something to do with the problem then. Nice! :)
Author
Owner

@x-magic commented on GitHub (Nov 14, 2022):

Okay... when I sleep with System Settings, wake up, quit system settings, and reopen System settings, this happens 🤣🤣🤣🤣

image

And the more sleeps there are, the more thread of those system settings app:
image

And this only happens on proper sleep, means the screen get darkens and locked (around 5s after sleep). Also happens both when the external monitor is connected or not. I have one external monitor connected. Tested with all other apps turned off, same.

Also noticed this:
image
(Note Family and Family (System Settings) are two different apps)

Not sure if it's helpful.

<!-- gh-comment-id:1313523604 --> @x-magic commented on GitHub (Nov 14, 2022): Okay... when I sleep with System Settings, wake up, quit system settings, and reopen System settings, this happens 🤣🤣🤣🤣 <img width="1710" alt="image" src="https://user-images.githubusercontent.com/3180639/201645344-43148590-7ddb-4e3f-a4dc-edb8b1325d29.png"> And the more sleeps there are, the more thread of those system settings app: <img width="871" alt="image" src="https://user-images.githubusercontent.com/3180639/201646800-508107d4-d4be-4a74-b5f2-50399cb66e41.png"> And this only happens on proper sleep, means the screen get darkens and locked (around 5s after sleep). Also happens both when the external monitor is connected or not. I have one external monitor connected. Tested with all other apps turned off, same. Also noticed this: <img width="204" alt="image" src="https://user-images.githubusercontent.com/3180639/201645732-432fdc91-dbfa-478a-96d2-25fb1d22dd94.png"> (Note *Family* and *Family (System Settings)* are two different apps) Not sure if it's helpful.
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

Super weird. Just as a test, can you try BetterDisplay to see if you experience the same phenomenon? Both app uses some similar stuff that might affect how System Settings behaves. Thanks!

<!-- gh-comment-id:1313550428 --> @waydabber commented on GitHub (Nov 14, 2022): Super weird. Just as a test, can you try [BetterDisplay](https://betterdisplay.app) to see if you experience the same phenomenon? Both app uses some similar stuff that might affect how System Settings behaves. Thanks!
Author
Owner

@hsugene commented on GitHub (Nov 14, 2022):

I can confirm that the issue occurs in BetterDisplay as well. Lunar seems to work fine, though.

Regarding your earlier comment, all relevant accessibility settings seem to be enabled and sleep seems to be necessary to make it happen reliably. I have to let it sleep for 5-10 seconds though. Less than that and the bug doesn’t occur reliably, perhaps because the Mac takes a bit of time to fully sleep?

<!-- gh-comment-id:1313565678 --> @hsugene commented on GitHub (Nov 14, 2022): I can confirm that the issue occurs in BetterDisplay as well. Lunar seems to work fine, though. Regarding your earlier comment, all relevant accessibility settings seem to be enabled and sleep seems to be necessary to make it happen reliably. I have to let it sleep for 5-10 seconds though. Less than that and the bug doesn’t occur reliably, perhaps because the Mac takes a bit of time to fully sleep?
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

All right, I'll investigate this, thanks for the info!

<!-- gh-comment-id:1313566555 --> @waydabber commented on GitHub (Nov 14, 2022): All right, I'll investigate this, thanks for the info!
Author
Owner

@hsugene commented on GitHub (Nov 14, 2022):

Oof, one correction: I had tested this with DisplayBuddy (which has the same bug) and not BetterDisplay. Got the names mixed up! I will follow up with a BetterDisplay test later today when I’m back in front of my Mac. Apologies for the confusion!

<!-- gh-comment-id:1313577263 --> @hsugene commented on GitHub (Nov 14, 2022): Oof, one correction: I had tested this with DisplayBuddy (which has the same bug) and not BetterDisplay. Got the names mixed up! I will follow up with a BetterDisplay test later today when I’m back in front of my Mac. Apologies for the confusion!
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

Ahh, all right. DisplayBuddy is an app I am not affiliated with (BetterDisplay is my doing so I can use it as a reference since I know the differences between MC and BD in-depth).

<!-- gh-comment-id:1313715335 --> @waydabber commented on GitHub (Nov 14, 2022): Ahh, all right. DisplayBuddy is an app I am not affiliated with (BetterDisplay is my doing so I can use it as a reference since I know the differences between MC and BD in-depth).
Author
Owner

@waydabber commented on GitHub (Nov 14, 2022):

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).

<!-- gh-comment-id:1314166008 --> @waydabber commented on GitHub (Nov 14, 2022): 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).
Author
Owner

@x-magic commented on GitHub (Nov 14, 2022):

True. Just downloaded BD and here are functions I can't get compared to MC:

  • DDC volume scaling (scale mapping curve)
  • DDC volume mute (when the monitor doesn't support mute via DDC)
    However it seems brightness control logic for built-in display is better (not sure why there's a difference, oh well)

Anyway I'm staying with MC but BD looks promising!

<!-- gh-comment-id:1314480396 --> @x-magic commented on GitHub (Nov 14, 2022): True. Just downloaded BD and here are functions I can't get compared to MC: - DDC volume scaling (scale mapping curve) - DDC volume mute (when the monitor doesn't support mute via DDC) However it seems brightness control logic for built-in display is better (not sure why there's a difference, oh well) Anyway I'm staying with MC but BD looks promising!
Author
Owner

@waydabber commented on GitHub (Nov 15, 2022):

Yes, the mapping curve is still missing from BD (you can play with the scale to compensate for this though). You can change the mute behavior here:

Screenshot 2022-11-15 at 7 22 27

So you were not able to reproduce the issue with BD, right, it was not just me?

<!-- gh-comment-id:1314832184 --> @waydabber commented on GitHub (Nov 15, 2022): Yes, the mapping curve is still missing from BD (you can play with the scale to compensate for this though). You can change the mute behavior here: <img width="942" alt="Screenshot 2022-11-15 at 7 22 27" src="https://user-images.githubusercontent.com/37590873/201842191-6fd61990-0652-4c74-b3d3-30227d446b63.png"> So you were not able to reproduce the issue with BD, right, it was not just me?
Author
Owner

@x-magic commented on GitHub (Nov 15, 2022):

Yes BD won't cause the issue with System Settings. Tried several time but can't reproduce so it's all good. Problem with MC still persist.

The volume scale mapping is way better because if I set the volume range to 0-16 it won't go max when I really need it. (Also another reason is that I don't want to enable finer control. Kind of OCD i guess).

DDC Mute won't work in BD for me either ticked or not ticked. In MC when DDC mute control option is not enabled, it emulates mute by set volume to 0 via DDC. However in BD it just won't mute, like mute feature is disabled entirely.

Anyway, I think I should cut off here as those issues should be raised in BD's issue logs. Would you like me to post them there instead? Cheers

<!-- gh-comment-id:1314838789 --> @x-magic commented on GitHub (Nov 15, 2022): Yes BD won't cause the issue with System Settings. Tried several time but can't reproduce so it's all good. Problem with MC still persist. The volume scale mapping is way better because if I set the volume range to 0-16 it won't go max when I really need it. (Also another reason is that I don't want to enable finer control. Kind of OCD i guess). DDC Mute won't work in BD for me either ticked or not ticked. In MC when DDC mute control option is not enabled, it emulates mute by set volume to 0 via DDC. However in BD it just won't mute, like mute feature is disabled entirely. Anyway, I think I should cut off here as those issues should be raised in BD's issue logs. Would you like me to post them there instead? Cheers
Author
Owner

@waydabber commented on GitHub (Nov 15, 2022):

Yes, thank you, please post the issue there - I'll fix it. I don't have a display with no mute support so any feedback is appreciated!

<!-- gh-comment-id:1314974018 --> @waydabber commented on GitHub (Nov 15, 2022): Yes, thank you, please post the issue there - I'll fix it. I don't have a display with no mute support so any feedback is appreciated!
Author
Owner

@owenzhao commented on GitHub (Dec 7, 2022):

A workaround, register didWakeNotification and restart MC each time when macOS wakes up.

https://developer.apple.com/documentation/appkit/nsworkspace/1530973-didwakenotification

<!-- gh-comment-id:1340745154 --> @owenzhao commented on GitHub (Dec 7, 2022): A workaround, register `didWakeNotification ` and restart MC each time when macOS wakes up. https://developer.apple.com/documentation/appkit/nsworkspace/1530973-didwakenotification
Author
Owner

@owenzhao commented on GitHub (Dec 11, 2022):

I wrote a tool that fixed this kind of issues. You can download it here.

https://github.com/owenzhao/App-Helper

截屏2022-12-11 12 39 14
<!-- gh-comment-id:1345456077 --> @owenzhao commented on GitHub (Dec 11, 2022): I wrote a tool that fixed this kind of issues. You can download it here. https://github.com/owenzhao/App-Helper <img width="618" alt="截屏2022-12-11 12 39 14" src="https://user-images.githubusercontent.com/2182896/206886780-fabbd40b-dc11-4f84-9663-173c14eccd18.png">
Author
Owner

@stale[bot] commented on GitHub (Dec 12, 2023):

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require attention? This issue may be closed if no further activity occurs. Thank you for your contributions.

<!-- gh-comment-id:1851219089 --> @stale[bot] commented on GitHub (Dec 12, 2023): Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require attention? This issue may be closed if no further activity occurs. Thank you for your contributions.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/MonitorControl#710
No description provided.