jaymonkey
Moderator
- Joined
- Aug 27, 2011
- Messages
- 4,080
- Motherboard
- GB Z490 Vision D
- CPU
- i9-10850K OC @ 5.2 GHz
- Graphics
- RX6800-XT+UHD630
- Mac
- Mobile Phone
MacOS - Sonoma
New wake from sleep Issue
If you have already implemented the Ventura fix detailed in the guide below but are experiencing new wake issues in Sonoma, you should first confirm the new wake reasons by referencing my post here :-
www.tonymacx86.com
If you confirm the new wake reasons to be due to CSPNEvaluation then you can implement the Sonoma specific fix in this post :-
www.tonymacx86.com
MacOS - Ventura
Random Wake from Sleep Issue
Like several others have reported in various threads, for example :-
www.tonymacx86.com
Both my Desktop Z490 Ventura systems (See White Knight in my sig for full spec) were suffering from non-user initiated wake from sleep events when running Ventura where as with Monterey and below they did not. I suspect that there are many users running Ventura who are currently unaware of the issue as they have simply not noticed it yet.
Before we go any further it's important to note that common causes of wake from sleep on a Hackintosh can be caused by badly configured USB ports, wake on LAN, incompatible USB devices ... etc, these issues are have been addressed multiple times in other guides and i will not cover those issues here.
Rather than just give you the solution, I've documented my investigations on the issue so that you have a good understanding of what the issue is and how i came to my solution. If you want to skip to just the solution scroll down to the section titled Method to stop system access to the AutoWake plist, that said i recommend you read the whole post/guide as there is important information and command examples that you may be unaware of.
Disclaimer: The following investigations, conclusions and solutions are my own take on this issue, at this time some assumptions have been made but i will do my best to further investigate and confirm these assumptions as time permits and will update this post as needed.
Since this issue seems to be an inherent feature of MacOS Ventura I suspect that some real Apple Mac's (Intel & AS) are also suffering from this issue. The solution I present at the end of this article should also work on genuine Mac's.
First Investigation (Wake Reasons)
We can use the following terminal command to get a quick summary of the MacOS Sleep/Wake system :-
Which will produce an output similar to this :-
This tells us the following :-
Next we need take a look at the specific wake reasons by entering the following Terminal command :-
Which will list all wake events since the last boot and will look something like this :-
Note: The above log example is a merged output from multiple systems so that I can show you the different types of wake reasons so it's unlikely you will see all of the above on a single system.
Lets examine the above log output ....
Wake reasons will be prefixed by one or more device id's (eg: XDCI, CNVW, PEGx, RP0x, RTC), followed by the type of wake reason in brackets '()'. With regards to this guide we can ignore these device id's with the exception of 'RTC'.
Wake reasons that end with
Wake reasons that end with
RTC Wakes are a known and well documented issue on Hackintosh and Real Macs. Luckily for us Hackintosh users, the OpenCore release package includes a handy kernel patch to disable RTC wakes which can be found in the
If you don't have a copy of the
Wake reasons that end in
Second Investigation (tcpkeepalive)
In the past we could disable scheduled PM wake events with the following terminal command :-
However on both my z490 desktop systems it appears that this command is not fully working in Ventura, despite it being accepted in Terminal and displaying the usual warning message that it will effect features like Find My Mac from working.
We can confirm if the command has been accepted/registered with the following Terminal command :-
This is what the command output looks like on my Z490 Desktop systems running Ventura :-
As you can see
If you find that the output of
Help if you Can - If your running MacOs Ventura it would be useful if you could confirm if
Survey Results to date
Confirmed SMBIOS with
For reference both my Z490 systems are running MacOS Ventura 13.1 and use the iMac20,2 SMBIOS (iMac 5K, 27" 2020).
So what can we conclude from this ?
It looks like Apple has deliberately disabled the
The fact that the
github.com
Third Investigation (Scheduled PM Wake Events)
Having proved that the
We can easily check for scheduled PM wake events by looking in System Information -> Power.
Scheduled PM wake events will be listed in the lower section of the right hand window like this :-
We can also use the following command to list the scheduled power events in Terminal :-
By comparing the listed events to the (ALARM) wake events listed by using the command
There are a few others but these two seem to be appearing more often, in previous versions of MacOS we could use the following Terminal commands to manually manage the listed scheduled PM wake events :-
Will cancel the currently listed events and :-
Should stop MacOS from creating any new power management events.
If you are unfamiliar with the Pmset command click on the following spoiler button for further help.
Note: If your viewing the events in System Information you must click on File -> Refresh Information to see the changes from the above commands.
Unfortunately in my investigation i found that these commands only seem to work in Ventura for the next few scheduled PM events and Ventura will eventually start creating new scheduled PM events, regardless of the fact that we have used the
The bottom line (as far as i can tell) is that right now there is no simple method to permanently disable scheduled PM wake events in MacOS Ventura on some desktop based Macs, and because both the
I hope i'm wrong but i fear i'm correct in this conclusion.
Of course on a desktop Hackintosh that is running on mains power these scheduled PM wake events are not that much of an issue, the system wakes up, does whatever the scheduled PM event was meant to do and then the system goes straight back to sleep. On my system scheduled PM wake events generally take 30-50 seconds to execute (from wake to back to sleep).
However there are instances where this behaviour on a desktop system could still be very annoying such as if the system was in someones bedroom or (as in my case) in the lounge.
Scheduled PM wakes (and RTC wakes) on a laptop based Hackintosh that is running/sleeping on battery power will obviously contribute to higher standby battery drain, something many Windows users are familiar with after Microsoft introduced Windows Modern Standby, in that case it is common for many users to find their laptop battery has been completely drained as the system has been busy whilst sleeping.
There is also the notion that did anybody ask for this behaviour ?, in most cases i suspect not, if i put my system to sleep, i expect it to stay asleep until I decide to wake it up. I do understand that sometimes scheduled wakes may be useful but the current default behaviour of a Desktop system waking up every few hours is simply not acceptable for most users.
If this was Apples intention then they should have told users about this behaviour in Ventura and ideally given users the ability to enable or disable the feature (with it disabled by default). I highly suspect that genuine Apple Mac's running Ventura are also suffering from this behaviour, unfortunately all my genuine Mac's are too old to run Ventura so i can not confirm this at this time.
So what can we do about it ?
My first attempt to curb the scheduled PM wake events in Ventura was to issue the following concatenated Terminal commands before the system sleeps and after it wakes :-
This would (in theory) either stop the scheduled PM wake events completely or at the very least reduce the number of scheduled PM wakes. I implemented it by using Better Touch Tool, which can run custom events before and after sleeping.
The result was around a 50% reduction in the number of wake events in a 24 hour period but i still found that the system was waking up at least six times or more during the night. Whilst this was progress, for me it was still unacceptable so more investigation was needed.
Fourth Investigation (Deeper Dive in to Scheduled PM Events)
I figured that the scheduled PM events must be saved somewhere in the MacOS system where the scheduler can read, write and delete PM events. My first thought was that they might be stored in NVRAM but this proved not to be the case.
After some digging around in the MacOS file system :-
I found that they are stored in a simple plist named
NOTE: On a clean install of MacOS Ventura or Sonoma it may take a while (up to a few hours) before the system creates the file
If we look at the contents of the plist we can see that each event matches those listed in System Information -> Power and by the Terminal command
Having identified where the system stores the scheduled PM events i wondered if i could use a similar technique to the one i use to permanently disable MacOS from re-opening apps on a restart/boot. The solution to that problem is to simply stop the system reading/writing to the plist that stores the currently open apps and window locations of the current session which i detailed in this thread :-
www.tonymacx86.com
The method i used for that solution was to change the ownership of the file and remove all the permissions which stopped the system from updating the file and thus permanently stopped MacOS from opening apps on any reboot/boot. That method worked because the file is located in the USERS Library folder (~/Library) but it would not work for the
Method to stop system access to the AutoWake plist
In some cases it may take one or two reboots for things to settle down and for the fix to take effect but i promise you that this solution works based on my own testing and feedback from other users.
If you need to undo the changes then simply remove the immutable flag with the Terminal command :-
If you are unfamiliar with the chflags command click on the following spoiler button for further help.
Syntax
chflags [-R [-H | -L | -P]] flags file ...
Options
-R Recurse: Change the file flags of file hierarchies rooted in the files
instead of just the files themselves.
-R -H Follow symbolic links on the command line
by default Symbolic links within the tree are not followed.
-R -L All symbolic links are followed.
-R -P No symbolic links are followed. (default)
The flags are specified as an octal number or a comma separated list of keywords.
hidden Set the hidden flag [Hide item from GUI]
Keywords and keyword aliases - Owner or Super-user only:
opaque Set the opaque flag
nodump Set the nodump flag
uappnd, uappend Set the user append-only flag
uchg, uchange, uimmutable Set the user immutable flag
uunlnk, uunlink Set the user undeletable flag
Keywords and keyword aliases - Super-user only:
arch, archived Set the archived flag
sappnd, sappend Set the system append-only flag
schg, schange, simmutable Set the system immutable flag
sunlnk, sunlink Set the system undeletable flag
The immutable flag makes the file/folder Locked/Protected and is equivalent to locking the file in Finder's Show Info box.
Putting the letters no before an option causes the flag to be turned off.
For example:
uchg Means the file cannot be changed
nouchg Means the file can be changed (immutable bit cleared)
hidden Will set the hidden flag
nohidden Will remove the hidden flag
In early versions of macOS locked/immutable files could not be deleted from the trashcan. In Mac OS X 10.1 and later locked files can easily be deleted by pressing press Shift-Option or Option key combination while emptying the Trash.
Symbolic links do not have flags, so unless the -H or -L option is set, chflags on a symbolic link always succeeds and has no effect. The -H, -L and -P options are ignored unless the -R option is specified. In addition, these options override each other and the command's actions are determined by the last one specified.
The sappnd and schg flags can only be unset when the system is in single-user mode. chflags(2).
Use ls -lO to see the flags of existing files.
The return status is zero if the mode is successfully changed,and >0 if an error occurs.
$ chflags uchg finance
Unlock the folder named "finance" and allow changes to all the contents:
$ chflags -R nouchg finance
Make the folder ~/Library visible (this was the default setting prior to OS X Lion).
$ chflags nohidden ~/Library
An alternative method to view the library is to use the 'Go' drop down menu in Finder and hold down the option key.
Hide the folder ~/Library from finder:
$ chflags hidden ~/Library
Make the file MyLogs.txt append-only:
$ chflags uappnd MyLogs.txt
Unlock your Documents directory and everything in it:
$ chflags -R nouchg ~/Documents
Warning: Please be aware that this method will stop ALL scheduled PM wake events from running which will effect features like Find My Mac so do not use it if you use these features or have planned scheduled events that need to run while the system is sleeping such as scheduled backups, email collection ..etc as the system will not wake up to execute them.
Since applying the above method i've not seen any scheduled PM wake events waking the system up while it is sleeping, so it appears that this method is working as expected. I will continue to monitor how well the method works over the next week or so and will update this post with more information if needed.
Update 22 Jan 2023
Since implementing this at the end of November 2022, the method continues to work perfectly with no Scheduled PM wakes or Dark Wakes in the last two weeks :-
New wake from sleep Issue
If you have already implemented the Ventura fix detailed in the guide below but are experiencing new wake issues in Sonoma, you should first confirm the new wake reasons by referencing my post here :-
[SOLVED] Ventura/Sonoma - Random (Scheduled PM) Wake from Sleep
Of course, it's macOS 14 (Sonoma). which mac are you using? Intel or Applesilicon?
www.tonymacx86.com
If you confirm the new wake reasons to be due to CSPNEvaluation then you can implement the Sonoma specific fix in this post :-
[SOLVED] Ventura/Sonoma - Random (Scheduled PM) Wake from Sleep
Looks like it’s being scheduled for certain times as well — my pc just woke up exactly at 00:00:00 UTC, midnight for me. I hope this helps somehow
www.tonymacx86.com
MacOS - Ventura
Random Wake from Sleep Issue
Like several others have reported in various threads, for example :-
Ventura Hackintosh Randomly wakes up
The thing looks like this, I have a new hackintosh everything works as it should just the problem lies in hibernation and more precisely: My computer wakes up from time to time (1-3h) with the screen off, turns on the fans and is in this state for 15 seconds and then goes back to sleep, what...
www.tonymacx86.com
Both my Desktop Z490 Ventura systems (See White Knight in my sig for full spec) were suffering from non-user initiated wake from sleep events when running Ventura where as with Monterey and below they did not. I suspect that there are many users running Ventura who are currently unaware of the issue as they have simply not noticed it yet.
Before we go any further it's important to note that common causes of wake from sleep on a Hackintosh can be caused by badly configured USB ports, wake on LAN, incompatible USB devices ... etc, these issues are have been addressed multiple times in other guides and i will not cover those issues here.
Rather than just give you the solution, I've documented my investigations on the issue so that you have a good understanding of what the issue is and how i came to my solution. If you want to skip to just the solution scroll down to the section titled Method to stop system access to the AutoWake plist, that said i recommend you read the whole post/guide as there is important information and command examples that you may be unaware of.
Disclaimer: The following investigations, conclusions and solutions are my own take on this issue, at this time some assumptions have been made but i will do my best to further investigate and confirm these assumptions as time permits and will update this post as needed.
Since this issue seems to be an inherent feature of MacOS Ventura I suspect that some real Apple Mac's (Intel & AS) are also suffering from this issue. The solution I present at the end of this article should also work on genuine Mac's.
First Investigation (Wake Reasons)
We can use the following terminal command to get a quick summary of the MacOS Sleep/Wake system :-
pmset -g statsWhich will produce an output similar to this :-
Code:
jay@WK-2-MACOS ~ % pmset -g stats
Sleep Count:5
Dark Wake Count:10
User Wake Count:4This tells us the following :-
- Number of times we have put the system to sleep (Sleep Count).
- Number of times the system has woken up automatically during sleep (Dark Wake Count).
- Number of times the user has woken the system (User Wake Count).
Next we need take a look at the specific wake reasons by entering the following Terminal command :-
log show --last boot --style syslog | fgrep "Wake reason"Which will list all wake events since the last boot and will look something like this :-
Code:
jay@WK-2_MACOS ~ % log show --last boot --style syslog | fgrep "Wake reason"
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW PEG2 PEG3 RP04 (User)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW PEG2 PEG3 RP04 (User)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: power-button PEG2 PEG3 RP04 (User)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: power-button PEG2 PEG3 RP04 (User)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: ARTC PEG2 PEG3 RP04 (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW PEG2 PEG3 RP04 (User)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: RTC (Alarm)
localhost kernel[0]: (AppleACPIPlatform) AppleACPIPlatformPower Wake reason: XDCI CNVW USBW PEG2 PEG3 RP04 (User)Note: The above log example is a merged output from multiple systems so that I can show you the different types of wake reasons so it's unlikely you will see all of the above on a single system.
Lets examine the above log output ....
Wake reasons will be prefixed by one or more device id's (eg: XDCI, CNVW, PEGx, RP0x, RTC), followed by the type of wake reason in brackets '()'. With regards to this guide we can ignore these device id's with the exception of 'RTC'.
Wake reasons that end with
(User) indicate when you have pressed a key on the keyboard, the power button or opened the lid on a laptop to wake the system from sleep, these are the types of wake event that most of us only want to see.Wake reasons that end with
(Alarm) with the device-id/prefix 'RTC' indicate when the systems Real Time Clock (RTC) has caused the system to wake from sleep. In my experience these tend to be only seen on systems that use a mobile SMBIOS (eg: MacBookPro14,x) so far I've never seen RTC wakes os systems that use a desktop SMBIOS. If any of you do see RTC (Alarm) wakes on a desktop system please let me know below so I can amend this section of the guide.RTC Wakes are a known and well documented issue on Hackintosh and Real Macs. Luckily for us Hackintosh users, the OpenCore release package includes a handy kernel patch to disable RTC wakes which can be found in the
Kernel -> Patch section of the Sample.plist config within the 'Docs' folder. If you see RTC (Alarm) wakes in your log you will most likely want to disable them, to do this simply use a code editor (I use BBEdit) to copy the 'Disable RTC wake scheduling' kernel patch code form the OpenCore Sample.plist and insert it into the Kernel -> Patch section of your config.plist, make sure to modify the value of <key>Enabled</key> to <true/>.If you don't have a copy of the
Sample.plist on hand you can click the Spoiler button below for the relevant kernel patch code that already has <key>Enabled</key> set to <true/>.
Code:
<dict>
<key>Arch</key>
<string>Any</string>
<key>Base</key>
<string>__ZN8AppleRTC18setupDateTimeAlarmEPK11RTCDateTime</string>
<key>Comment</key>
<string>Disable RTC wake scheduling</string>
<key>Count</key>
<integer>1</integer>
<key>Enabled</key>
<false/>
<key>Find</key>
<data></data>
<key>Identifier</key>
<string>com.apple.driver.AppleRTC</string>
<key>Limit</key>
<integer>0</integer>
<key>Mask</key>
<data></data>
<key>MaxKernel</key>
<string></string>
<key>MinKernel</key>
<string>19.0.0</string>
<key>Replace</key>
<data>ww==</data>
<key>ReplaceMask</key>
<data></data>
<key>Skip</key>
<integer>0</integer>
</dict>Wake reasons that end in
(Alarm) without the 'RTC' device-id/prefix indicate that MacOS caused the system to wake up via a scheduled PM (Power Management) Wake event and it is these events that are the root cause of what some users are reporting as random wakes from sleep in Ventura and is what we will concentrate on for the rest of this investigation.Second Investigation (tcpkeepalive)
In the past we could disable scheduled PM wake events with the following terminal command :-
sudo pmset -a tcpkeepalive 0However on both my z490 desktop systems it appears that this command is not fully working in Ventura, despite it being accepted in Terminal and displaying the usual warning message that it will effect features like Find My Mac from working.
Code:
jay@MonkeyMac-Pro-WK-20 ~ % sudo pmset -a tcpkeepalive 0
Warning: This option disables TCP Keep Alive mechanism when sytem is sleeping.
This will result in some critical features like 'Find My Mac' not to function properly.We can confirm if the command has been accepted/registered with the following Terminal command :-
pmset -gThis is what the command output looks like on my Z490 Desktop systems running Ventura :-
Code:
jay@WK-2_MACOS ~ % pmset -g
System-wide power settings:
Currently in use:
standby 0
Sleep On Power Button 1
womp 0
autorestart 0
hibernatefile /var/vm/sleepimage
proximitywake 0
powernap 0
networkoversleep 0
disksleep 10
standbydelayhigh 86400
sleep 1
hibernatemode 0
ttyskeepawake 1
displaysleep 30
highstandbythreshold 50
standbydelaylow 86400As you can see
tcpkeepalive 0 is missing from the list.If you find that the output of
pmset -g includes tcpkeepalive and you set it to 0 using the command sudo pmset -a tcpkeepalive 0 then there is a good chance you don't need to do anything else as this should disable scheduled PM wakes, however since this does not work on my system I can not fully confirm if this is the case.Help if you Can - If your running MacOs Ventura it would be useful if you could confirm if
tcpkeepalive is working on your system in a post below, as this will help to establish the extent of the issue, please state which version of MacOS you are running and which SMBIOS you are using, if you have multiple systems it would also help if you could include what motherboard and CPU generation you are using, please also include the output of pmset -g.Survey Results to date
Confirmed SMBIOS with
tcpkeepalive not Working- iMac18,1
- iMac19,1
- iMac20,2
- MacPro6,1
- MacPro7,1 **
tcpkeepalive Working- iMacPro1,1
- MacPro7,1 **
tcpkeepalive is working and not working, so not sure what to make of that ??For reference both my Z490 systems are running MacOS Ventura 13.1 and use the iMac20,2 SMBIOS (iMac 5K, 27" 2020).
So what can we conclude from this ?
It looks like Apple has deliberately disabled the
pmset tcpkeepalive command in recent versions of MacOS on some Mac models. As to why it only effects some desktop models and not others is a mystery (further investigation needed).The fact that the
pmset tcpkeepalive command works on some Mac models but not others gives me hope that it can be re-enabled with a kernel patch, similar to how the FeatureUnlock kext can unlock certain features when running a SMBIOS that does not support them. This approach will need much a deeper investigation in to the kernel but should (in theory) be possible, I have already submitted this as a feature request to the acidanthera devlopemnt team, you can use the following link to view the request:-[Feature Request] - FetureUnlock - re-enable tcpkeepalive · Issue #2208 · acidanthera/bugtracker
Hi Guys, It seems that in Ventura and later releases of Monterey on some desktop macs the power management tcpkeepalive parameter is not being registered. In the past we have been able to use pmset...
github.com
Third Investigation (Scheduled PM Wake Events)
Having proved that the
pmset tcpkeepalive command is not working anymore on my two desktop systems, I shifted my focus to the Scheduled PM events themselves. Although i cant prove it at this time I suspect that Ventura is generating many more scheduled PM wake events then previous versions of MacOS simply because one of my Z490 systems is in my lounge and i noticed that since upgrading to Ventura it was waking up many times during the day and night when the system was sleeping, which it did not do when running older versions of MacOS. It's also possible that the number of scheduled wakes are the same as in previous versions of MacOS but due to the pmset tcpkeepalive command no longer working they are more noticeable.We can easily check for scheduled PM wake events by looking in System Information -> Power.
Scheduled PM wake events will be listed in the lower section of the right hand window like this :-
We can also use the following command to list the scheduled power events in Terminal :-
pmset -g schedBy comparing the listed events to the (ALARM) wake events listed by using the command
log show --last boot --style syslog | fgrep "Wake reason" we can deduce that the main causes of the wake events in Ventura are caused by the following two scheduled events :-
Code:
com.apple.alarm.user-visible-com.apple.CalendarNotification.EKTravelEngine.periodicRefreshTimer
com.apple.alarm.user-visible-com.apple.acmd.alarmThere are a few others but these two seem to be appearing more often, in previous versions of MacOS we could use the following Terminal commands to manually manage the listed scheduled PM wake events :-
sudo pmset schedule cancelallWill cancel the currently listed events and :-
sudo pmset repeat cancelShould stop MacOS from creating any new power management events.
If you are unfamiliar with the Pmset command click on the following spoiler button for further help.
pmset
manipulate power management settings
SYNOPSIS
pmset [-a | -b | -c | -u] [setting value] [...]
pmset -u [haltlevel percent] [haltafter minutes] [haltremain minutes]
pmset -g [option]
pmset schedule [cancel | cancelall] type date+time [owner]
pmset repeat cancel
pmset repeat type weekdays time
pmset relative [wake | poweron] seconds
pmset [touch | sleepnow | displaysleepnow | boot]
DESCRIPTION
pmset manages power management settings such as idle sleep timing, wake on administrative access, automatic restart on power loss, etc.
Note that processes may dynamically override these power management settings by using I/O Kit power assertions. Whenever processes override any system power settings, pmset will list those processes and their power assertions in -g and -g assertions. See caffeinate(8).
SETTING
pmset can modify the values of any of the power management settings defined below. You may specify one or more setting & value pairs on the command-line invocation of pmset. The -a, -b, -c, -u flags determine whether the settings apply to battery ( -b ), charger (wall power) ( -c ), UPS ( -u ) or all ( -a ).
Use a minutes argument of 0 to set the idle time to never for sleep disksleep and displaysleep
pmset must be run as root in order to modify any settings.
SETTINGS
displaysleep - display sleep timer; replaces 'dim' argument in 10.4 (value in minutes, or 0 to disable)
disksleep - disk spindown timer; replaces 'spindown' argument in 10.4 (value in minutes, or 0 to disable)
sleep - system sleep timer (value in minutes, or 0 to disable)
womp - wake on ethernet magic packet (value = 0/1). Same as "Wake for network access" in System Settings.
ring - wake on modem ring (value = 0/1)
powernap - enable/disable Power Nap on supported machines (value = 0/1)
proximitywake - On supported systems, this option controls system wake from sleep
autorestart - automatic restart on power loss (value = 0/1)
lidwake - wake the machine when the laptop lid (or clamshell) is opened (value = 0/1)
acwake - wake the machine when power source (AC/battery) is changed (value = 0/1)
lessbright - slightly turn down display brightness when switching to this power source (value = 0/1)
halfdim - display sleep will use an intermediate half-brightness state between full brightness and fully off
sms - use Sudden Motion Sensor to park disk heads on sudden changes in G force (value = 0/1)
hibernatemode - change hibernation mode. Please use caution. (value =integer)
hibernatefile - change hibernation image file location. Image may only be located on the root volume.
ttyskeepawake - prevent idle system sleep when any tty (e.g. remote login session)
networkoversleep - this setting affects how OS X networking presents shared network services
destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode.
GETTING
-g (with no argument) will display the settings currently in use.
-g live displays the settings currently in use.
-g custom displays custom settings for all power sources.
-g cap displays which power management features the machine supports.
-g sched displays scheduled startup/wake and shutdown/sleep events.
-g ups displays UPS emergency thresholds.
-g ps / batt displays status of batteries and UPSs.
-g pslog displays an ongoing log of power source (battery and UPS) state.
-g rawlog displays an ongoing log of battery state as read directly from battery.
-g therm shows thermal conditions that affect CPU speed. Not available on all platforms.
-g thermlog shows a log of thermal notifications that affect CPU speed. Not available on all platforms.
-g assertions displays a summary of power assertions. Assertions may prevent system sleep or display sleep.
-g assertionslog shows a log of assertion creations and releases.
-g sysload displays the "system load advisory" - a summary of system activity
-g sysloadlog displays an ongoing log of lives changes to the system load advisory
-g ac / adapter will display details about an attached AC power adapter.
-g log displays a history of sleeps, wakes, and other power management events.
-g uuid displays the currently active sleep/wake UUID
-g uuidlog displays the currently active sleep/wake UUID, and prints a new UUID
-g history is a debugging tool. Prints a timeline of system sleeplwake UUIDs
-g historydetailed Prints driver-level timings for a sleep/wake. Pass a UUID as an argument.
-g powerstate [class names] Prints the current power states for I/O Kit drivers.
-g powerstatelog [-i interval] [class names] Periodically prints the power state residency times
-g stats Prints the counts for number sleeps and wakes system has gone thru since boot.
-g systemstate Prints the current power state of the system and available capabilites.
-g everything Prints output from every argument under the GETTING header.
SAFE SLEEP ARGUMENTS
hibernatemode supports values of 0, 3, or 25. Whether or not a hibernation image gets written is also dependent on the values of standby and autopoweroff
For example, on desktops that support standby a hibernation image will be written after the specified standbydelay time. To disable hibernation images completely, ensure hibernatemode standby and autopoweroff are all set to 0.
hibernatemode = 0 by default on desktops. The system will not back memory up to persistent storage. The system must wake from the contents of memory; the system will lose context on power loss. This is, historically, plain old sleep.
hibernatemode = 3 by default on portables. The system will store a copy of memory to persistent storage (the disk), and will power memory during sleep. The system will wake from memory, unless a power loss forces it to restore from hibernate image.
hibernatemode = 25 is only settable via pmset. The system will store a copy of memory to persistent storage (the disk), and will remove power to memory. The system will restore from disk image. If you want "hibernation" - slower sleeps, slower wakes, and better battery life, you should use this setting.
Please note that hibernatefile may only point to a file located on the root volume.
STANDBY ARGUMENTS
standby causes kernel power management to automatically hibernate a machine after it has slept for a specified time period. This saves power while asleep. This setting defaults to ON for supported hardware. The setting standby will be visible in pmset -g if the feature is supported on this machine.
standbydelayhigh and standbydelaylow specify the delay, in seconds, before writing the hibernation image to disk and powering off memory for Standby. standbydelayhigh is used when the remaining battery capacity is above highstandbythreshold , and standbydelaylow is used when the remaining battery capacity is below highstandbythreshold.
highstandbythreshold has a default value of 50 percent.
autopoweroff is enabled by default on supported platforms as an implementation of Lot 6 to the European Energy-related Products Directive. After sleeping for <autopoweroffdelay> seconds, the system will write a hibernation image and go into a lower power chipset sleep. Wakeups from this state will take longer than wakeups from regular sleep.
autopoweroffdelay specifies the delay, in seconds, before entering autopoweroff mode.
UPS SPECIFIC ARGUMENTS
UPS-specific arguments are only valid following the -u option. UPS settings also have an on/off value. Use a -1 argument instead of percent or minutes to turn any of these settings off. If multiple halt conditions are specified, the system will halt on the first condition that occurs in a low power situation.
haltlevel - when draining UPS battery, battery level at which to trigger an emergency shutdown (value in %)
haltafter - when draining UPS battery, trigger emergency shutdown after this long running on UPS power (value in minutes, or 0 to disable)
haltremain - when draining UPS battery, trigger emergency shutdown when this much time remaining on UPS power is estimated (value in minutes, or 0 to disable)
Note: None of these settings are observed on a system with support for an internal battery, such as a laptop. UPS emergency shutdown settings are for desktop and server only.
SCHEDULED EVENT ARGUMENTS
pmset allows you to schedule system sleep, shutdown, wakeup and/or power on. "schedule" is for setting up one-time power events, and "repeat" is for setting up daily/weekly power on and power off events. Note that you may only have one pair of repeating events scheduled - a "power on" event and a "power off" event. For sleep cycling applications, pmset can schedule a "relative" wakeup or poweron to occur in seconds from the end of system sleep/shutdown, but this event cannot be cancelled and is inherently imprecise.
type - one of sleep, wake, poweron, shutdown, wakeorpoweron
date/time - "MM/dd/yy HH:mm:ss" (in 24 hour format; must be in quotes)
time - HH:mm:ss
weekdays - a subset of MTWRFSU ("M" and "MTWRF" are valid strings)
owner - a string describing the person or program who is scheduling this one-time power event (optional)
POWER SOURCE ARGUMENTS
-g with a 'batt' or 'ps' argument will show the state of all attached power sources.
-g with a 'pslog' or 'rawlog' argument is normally used for debugging, such as isolating a problem with an aging battery.
OTHER ARGUMENTS
boot - tell the kernel that system boot is complete (normally LoginWindow does this).
touch - PM re-reads existing settings from disk.
noidle - pmset prevents idle sleep by creating a PM assertion to prevent idle sleep(while running; hit ctrl-c to
cancel). This argument is deprecated in favor of caffeinate(8). Please use caffeinate(8) instead.
sleepnow - causes an immediate system sleep.
restoredefaults - Restores power management settings to their default values.
displaysleepnow - causes display to go to sleep immediately.
resetdisplayambientparams - resets the ambient light parameters for certain Apple displays.
dim - deprecated in 10.4 in favor of 'displaysleep'. 'dim' will continue to work.
spindown - deprecated in 10.4 in favor of 'disksleep'. 'spindown' will continue to work.
EXAMPLES
This command sets displaysleep to a 5 minute timer on battery power, leaving other settings on battery power and other power sources unperturbed.
pmset -b displaysleep 5
Sets displaysleep to 10, disksleep to 10, system sleep to 30, and turns on WakeOnMagicPacket for ALL power sources (AC, Battery, and UPS) as appropriate
pmset -a displaysleep 10 disksleep 10 sleep 30 womp 1
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown when UPS battery drains to below 40%.
pmset -u haltlevel 40
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown when UPS battery drains to below 25%, or when the UPS estimates it has less than 30 minutes remaining runtime. The system shuts down as soon as either of these conditions is met.
pmset -u haltlevel 25 haltremain 30
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown after 2 minutes of running on UPS battery power.
pmset -u haltafter 2
Schedules the system to automatically wake from sleep on July 4, 2016, at 8PM.
pmset schedule wake "07/04/16 20:00:00"
Schedules a repeating shutdown to occur each day, Tuesday through Saturday, at 11AM.
pmset repeat shutdown TWRFS 11:00:00
Schedules a repeating wake or power on event every tuesday at 12:00 noon, and a repeating sleep event every night at 8:00 PM.
pmset repeat wakeorpoweron T 12:00:00 sleep MTWRFSU 20:00:00
Cancels all scheduled system sleep, shutdown, wake, and power on events.
pmset repeat cancel
Prints the power management settings in use by the system.
pmset -g
Prints a snapshot of battery/power source state at the moment.
pmset -g batt
If your system suddenly sleeps on battery power with 20-50% of capacity remaining, leave this command running in a Terminal window. When you see the problem and later power and wake the computer, you'll be able to detect sudden discontinuities (like a jump from 30% to 0%) indicative of an aging battery.
pmset -g pslog
manipulate power management settings
SYNOPSIS
pmset [-a | -b | -c | -u] [setting value] [...]
pmset -u [haltlevel percent] [haltafter minutes] [haltremain minutes]
pmset -g [option]
pmset schedule [cancel | cancelall] type date+time [owner]
pmset repeat cancel
pmset repeat type weekdays time
pmset relative [wake | poweron] seconds
pmset [touch | sleepnow | displaysleepnow | boot]
DESCRIPTION
pmset manages power management settings such as idle sleep timing, wake on administrative access, automatic restart on power loss, etc.
Note that processes may dynamically override these power management settings by using I/O Kit power assertions. Whenever processes override any system power settings, pmset will list those processes and their power assertions in -g and -g assertions. See caffeinate(8).
SETTING
pmset can modify the values of any of the power management settings defined below. You may specify one or more setting & value pairs on the command-line invocation of pmset. The -a, -b, -c, -u flags determine whether the settings apply to battery ( -b ), charger (wall power) ( -c ), UPS ( -u ) or all ( -a ).
Use a minutes argument of 0 to set the idle time to never for sleep disksleep and displaysleep
pmset must be run as root in order to modify any settings.
SETTINGS
displaysleep - display sleep timer; replaces 'dim' argument in 10.4 (value in minutes, or 0 to disable)
disksleep - disk spindown timer; replaces 'spindown' argument in 10.4 (value in minutes, or 0 to disable)
sleep - system sleep timer (value in minutes, or 0 to disable)
womp - wake on ethernet magic packet (value = 0/1). Same as "Wake for network access" in System Settings.
ring - wake on modem ring (value = 0/1)
powernap - enable/disable Power Nap on supported machines (value = 0/1)
proximitywake - On supported systems, this option controls system wake from sleep
autorestart - automatic restart on power loss (value = 0/1)
lidwake - wake the machine when the laptop lid (or clamshell) is opened (value = 0/1)
acwake - wake the machine when power source (AC/battery) is changed (value = 0/1)
lessbright - slightly turn down display brightness when switching to this power source (value = 0/1)
halfdim - display sleep will use an intermediate half-brightness state between full brightness and fully off
sms - use Sudden Motion Sensor to park disk heads on sudden changes in G force (value = 0/1)
hibernatemode - change hibernation mode. Please use caution. (value =integer)
hibernatefile - change hibernation image file location. Image may only be located on the root volume.
ttyskeepawake - prevent idle system sleep when any tty (e.g. remote login session)
networkoversleep - this setting affects how OS X networking presents shared network services
destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode.
GETTING
-g (with no argument) will display the settings currently in use.
-g live displays the settings currently in use.
-g custom displays custom settings for all power sources.
-g cap displays which power management features the machine supports.
-g sched displays scheduled startup/wake and shutdown/sleep events.
-g ups displays UPS emergency thresholds.
-g ps / batt displays status of batteries and UPSs.
-g pslog displays an ongoing log of power source (battery and UPS) state.
-g rawlog displays an ongoing log of battery state as read directly from battery.
-g therm shows thermal conditions that affect CPU speed. Not available on all platforms.
-g thermlog shows a log of thermal notifications that affect CPU speed. Not available on all platforms.
-g assertions displays a summary of power assertions. Assertions may prevent system sleep or display sleep.
-g assertionslog shows a log of assertion creations and releases.
-g sysload displays the "system load advisory" - a summary of system activity
-g sysloadlog displays an ongoing log of lives changes to the system load advisory
-g ac / adapter will display details about an attached AC power adapter.
-g log displays a history of sleeps, wakes, and other power management events.
-g uuid displays the currently active sleep/wake UUID
-g uuidlog displays the currently active sleep/wake UUID, and prints a new UUID
-g history is a debugging tool. Prints a timeline of system sleeplwake UUIDs
-g historydetailed Prints driver-level timings for a sleep/wake. Pass a UUID as an argument.
-g powerstate [class names] Prints the current power states for I/O Kit drivers.
-g powerstatelog [-i interval] [class names] Periodically prints the power state residency times
-g stats Prints the counts for number sleeps and wakes system has gone thru since boot.
-g systemstate Prints the current power state of the system and available capabilites.
-g everything Prints output from every argument under the GETTING header.
SAFE SLEEP ARGUMENTS
hibernatemode supports values of 0, 3, or 25. Whether or not a hibernation image gets written is also dependent on the values of standby and autopoweroff
For example, on desktops that support standby a hibernation image will be written after the specified standbydelay time. To disable hibernation images completely, ensure hibernatemode standby and autopoweroff are all set to 0.
hibernatemode = 0 by default on desktops. The system will not back memory up to persistent storage. The system must wake from the contents of memory; the system will lose context on power loss. This is, historically, plain old sleep.
hibernatemode = 3 by default on portables. The system will store a copy of memory to persistent storage (the disk), and will power memory during sleep. The system will wake from memory, unless a power loss forces it to restore from hibernate image.
hibernatemode = 25 is only settable via pmset. The system will store a copy of memory to persistent storage (the disk), and will remove power to memory. The system will restore from disk image. If you want "hibernation" - slower sleeps, slower wakes, and better battery life, you should use this setting.
Please note that hibernatefile may only point to a file located on the root volume.
STANDBY ARGUMENTS
standby causes kernel power management to automatically hibernate a machine after it has slept for a specified time period. This saves power while asleep. This setting defaults to ON for supported hardware. The setting standby will be visible in pmset -g if the feature is supported on this machine.
standbydelayhigh and standbydelaylow specify the delay, in seconds, before writing the hibernation image to disk and powering off memory for Standby. standbydelayhigh is used when the remaining battery capacity is above highstandbythreshold , and standbydelaylow is used when the remaining battery capacity is below highstandbythreshold.
highstandbythreshold has a default value of 50 percent.
autopoweroff is enabled by default on supported platforms as an implementation of Lot 6 to the European Energy-related Products Directive. After sleeping for <autopoweroffdelay> seconds, the system will write a hibernation image and go into a lower power chipset sleep. Wakeups from this state will take longer than wakeups from regular sleep.
autopoweroffdelay specifies the delay, in seconds, before entering autopoweroff mode.
UPS SPECIFIC ARGUMENTS
UPS-specific arguments are only valid following the -u option. UPS settings also have an on/off value. Use a -1 argument instead of percent or minutes to turn any of these settings off. If multiple halt conditions are specified, the system will halt on the first condition that occurs in a low power situation.
haltlevel - when draining UPS battery, battery level at which to trigger an emergency shutdown (value in %)
haltafter - when draining UPS battery, trigger emergency shutdown after this long running on UPS power (value in minutes, or 0 to disable)
haltremain - when draining UPS battery, trigger emergency shutdown when this much time remaining on UPS power is estimated (value in minutes, or 0 to disable)
Note: None of these settings are observed on a system with support for an internal battery, such as a laptop. UPS emergency shutdown settings are for desktop and server only.
SCHEDULED EVENT ARGUMENTS
pmset allows you to schedule system sleep, shutdown, wakeup and/or power on. "schedule" is for setting up one-time power events, and "repeat" is for setting up daily/weekly power on and power off events. Note that you may only have one pair of repeating events scheduled - a "power on" event and a "power off" event. For sleep cycling applications, pmset can schedule a "relative" wakeup or poweron to occur in seconds from the end of system sleep/shutdown, but this event cannot be cancelled and is inherently imprecise.
type - one of sleep, wake, poweron, shutdown, wakeorpoweron
date/time - "MM/dd/yy HH:mm:ss" (in 24 hour format; must be in quotes)
time - HH:mm:ss
weekdays - a subset of MTWRFSU ("M" and "MTWRF" are valid strings)
owner - a string describing the person or program who is scheduling this one-time power event (optional)
POWER SOURCE ARGUMENTS
-g with a 'batt' or 'ps' argument will show the state of all attached power sources.
-g with a 'pslog' or 'rawlog' argument is normally used for debugging, such as isolating a problem with an aging battery.
OTHER ARGUMENTS
boot - tell the kernel that system boot is complete (normally LoginWindow does this).
touch - PM re-reads existing settings from disk.
noidle - pmset prevents idle sleep by creating a PM assertion to prevent idle sleep(while running; hit ctrl-c to
cancel). This argument is deprecated in favor of caffeinate(8). Please use caffeinate(8) instead.
sleepnow - causes an immediate system sleep.
restoredefaults - Restores power management settings to their default values.
displaysleepnow - causes display to go to sleep immediately.
resetdisplayambientparams - resets the ambient light parameters for certain Apple displays.
dim - deprecated in 10.4 in favor of 'displaysleep'. 'dim' will continue to work.
spindown - deprecated in 10.4 in favor of 'disksleep'. 'spindown' will continue to work.
EXAMPLES
This command sets displaysleep to a 5 minute timer on battery power, leaving other settings on battery power and other power sources unperturbed.
pmset -b displaysleep 5
Sets displaysleep to 10, disksleep to 10, system sleep to 30, and turns on WakeOnMagicPacket for ALL power sources (AC, Battery, and UPS) as appropriate
pmset -a displaysleep 10 disksleep 10 sleep 30 womp 1
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown when UPS battery drains to below 40%.
pmset -u haltlevel 40
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown when UPS battery drains to below 25%, or when the UPS estimates it has less than 30 minutes remaining runtime. The system shuts down as soon as either of these conditions is met.
pmset -u haltlevel 25 haltremain 30
For a system with an attached and supported UPS, this instructs the system to perform an emergency shutdown after 2 minutes of running on UPS battery power.
pmset -u haltafter 2
Schedules the system to automatically wake from sleep on July 4, 2016, at 8PM.
pmset schedule wake "07/04/16 20:00:00"
Schedules a repeating shutdown to occur each day, Tuesday through Saturday, at 11AM.
pmset repeat shutdown TWRFS 11:00:00
Schedules a repeating wake or power on event every tuesday at 12:00 noon, and a repeating sleep event every night at 8:00 PM.
pmset repeat wakeorpoweron T 12:00:00 sleep MTWRFSU 20:00:00
Cancels all scheduled system sleep, shutdown, wake, and power on events.
pmset repeat cancel
Prints the power management settings in use by the system.
pmset -g
Prints a snapshot of battery/power source state at the moment.
pmset -g batt
If your system suddenly sleeps on battery power with 20-50% of capacity remaining, leave this command running in a Terminal window. When you see the problem and later power and wake the computer, you'll be able to detect sudden discontinuities (like a jump from 30% to 0%) indicative of an aging battery.
pmset -g pslog
Note: If your viewing the events in System Information you must click on File -> Refresh Information to see the changes from the above commands.
Unfortunately in my investigation i found that these commands only seem to work in Ventura for the next few scheduled PM events and Ventura will eventually start creating new scheduled PM events, regardless of the fact that we have used the
sudo pmset repeat cancel command.The bottom line (as far as i can tell) is that right now there is no simple method to permanently disable scheduled PM wake events in MacOS Ventura on some desktop based Macs, and because both the
pmset tcpkeepalive command is not working and the command to cancel repeat scheduled wake events also does not work as expected, it would suggest that this behaviour is by design.I hope i'm wrong but i fear i'm correct in this conclusion.
Of course on a desktop Hackintosh that is running on mains power these scheduled PM wake events are not that much of an issue, the system wakes up, does whatever the scheduled PM event was meant to do and then the system goes straight back to sleep. On my system scheduled PM wake events generally take 30-50 seconds to execute (from wake to back to sleep).
However there are instances where this behaviour on a desktop system could still be very annoying such as if the system was in someones bedroom or (as in my case) in the lounge.
Scheduled PM wakes (and RTC wakes) on a laptop based Hackintosh that is running/sleeping on battery power will obviously contribute to higher standby battery drain, something many Windows users are familiar with after Microsoft introduced Windows Modern Standby, in that case it is common for many users to find their laptop battery has been completely drained as the system has been busy whilst sleeping.
There is also the notion that did anybody ask for this behaviour ?, in most cases i suspect not, if i put my system to sleep, i expect it to stay asleep until I decide to wake it up. I do understand that sometimes scheduled wakes may be useful but the current default behaviour of a Desktop system waking up every few hours is simply not acceptable for most users.
If this was Apples intention then they should have told users about this behaviour in Ventura and ideally given users the ability to enable or disable the feature (with it disabled by default). I highly suspect that genuine Apple Mac's running Ventura are also suffering from this behaviour, unfortunately all my genuine Mac's are too old to run Ventura so i can not confirm this at this time.
So what can we do about it ?
My first attempt to curb the scheduled PM wake events in Ventura was to issue the following concatenated Terminal commands before the system sleeps and after it wakes :-
sudo pmset schedule cancelall; pmset repeat cancelThis would (in theory) either stop the scheduled PM wake events completely or at the very least reduce the number of scheduled PM wakes. I implemented it by using Better Touch Tool, which can run custom events before and after sleeping.
The result was around a 50% reduction in the number of wake events in a 24 hour period but i still found that the system was waking up at least six times or more during the night. Whilst this was progress, for me it was still unacceptable so more investigation was needed.
Fourth Investigation (Deeper Dive in to Scheduled PM Events)
I figured that the scheduled PM events must be saved somewhere in the MacOS system where the scheduler can read, write and delete PM events. My first thought was that they might be stored in NVRAM but this proved not to be the case.
After some digging around in the MacOS file system :-
I found that they are stored in a simple plist named
com.apple.AutoWake.plist at the following location :-/Library/Preferences/SystemConfiguration/NOTE: On a clean install of MacOS Ventura or Sonoma it may take a while (up to a few hours) before the system creates the file
com.apple.AutoWake.plist file ... just wait and you eventually see it.If we look at the contents of the plist we can see that each event matches those listed in System Information -> Power and by the Terminal command
pmset -g sched. Further proof can be found by executing the command sudo pmset schedule cancelall after which the plist is empty except for a small code header :-Having identified where the system stores the scheduled PM events i wondered if i could use a similar technique to the one i use to permanently disable MacOS from re-opening apps on a restart/boot. The solution to that problem is to simply stop the system reading/writing to the plist that stores the currently open apps and window locations of the current session which i detailed in this thread :-
[GUIDE] Permanently disable MacOS from re-opening Apps on restart/boot
Background Despite MacOS presenting a dialogue box that gives you the option to reopen (or not) apps on a restart or shutdown, in my experience I've found that most times MacOS seem to ignore whatever option you select and just goes ahead and reopens the previous open apps regardless .... even...
www.tonymacx86.com
The method i used for that solution was to change the ownership of the file and remove all the permissions which stopped the system from updating the file and thus permanently stopped MacOS from opening apps on any reboot/boot. That method worked because the file is located in the USERS Library folder (~/Library) but it would not work for the
com.apple.AutoWake.plist as it resides within the secure and locked MacOS system drive so we need to use a different command to achieve a similar result.Method to stop system access to the AutoWake plist
- Open Terminal
- First make sure the
com.apple.AutoWake.plistfile is empty by using the following command :- sudo pmset sched cancelall- Next we need to set the immutable flag to lock/protect the file using the
chflagscommand :- sudo chflags schg /Library/Preferences/SystemConfiguration/com.apple.AutoWake.plist- Reboot the System
com.apple.AutoWake.plist file (but still read from it) and thus stop scheduled PM wake events.In some cases it may take one or two reboots for things to settle down and for the fix to take effect but i promise you that this solution works based on my own testing and feedback from other users.
If you need to undo the changes then simply remove the immutable flag with the Terminal command :-
sudo chflags noschg /Library/Preferences/SystemConfiguration/com.apple.AutoWake.plistIf you are unfamiliar with the chflags command click on the following spoiler button for further help.
chflags
Change a file or folder's flags.Syntax
chflags [-R [-H | -L | -P]] flags file ...
Options
-R Recurse: Change the file flags of file hierarchies rooted in the files
instead of just the files themselves.
-R -H Follow symbolic links on the command line
by default Symbolic links within the tree are not followed.
-R -L All symbolic links are followed.
-R -P No symbolic links are followed. (default)
The flags are specified as an octal number or a comma separated list of keywords.
hidden Set the hidden flag [Hide item from GUI]
Keywords and keyword aliases - Owner or Super-user only:
opaque Set the opaque flag
nodump Set the nodump flag
uappnd, uappend Set the user append-only flag
uchg, uchange, uimmutable Set the user immutable flag
uunlnk, uunlink Set the user undeletable flag
Keywords and keyword aliases - Super-user only:
arch, archived Set the archived flag
sappnd, sappend Set the system append-only flag
schg, schange, simmutable Set the system immutable flag
sunlnk, sunlink Set the system undeletable flag
The immutable flag makes the file/folder Locked/Protected and is equivalent to locking the file in Finder's Show Info box.
Putting the letters no before an option causes the flag to be turned off.
For example:
uchg Means the file cannot be changed
nouchg Means the file can be changed (immutable bit cleared)
hidden Will set the hidden flag
nohidden Will remove the hidden flag
In early versions of macOS locked/immutable files could not be deleted from the trashcan. In Mac OS X 10.1 and later locked files can easily be deleted by pressing press Shift-Option or Option key combination while emptying the Trash.
Symbolic links do not have flags, so unless the -H or -L option is set, chflags on a symbolic link always succeeds and has no effect. The -H, -L and -P options are ignored unless the -R option is specified. In addition, these options override each other and the command's actions are determined by the last one specified.
The sappnd and schg flags can only be unset when the system is in single-user mode. chflags(2).
Use ls -lO to see the flags of existing files.
The return status is zero if the mode is successfully changed,and >0 if an error occurs.
Examples
Lock the folder "finance" against changes:$ chflags uchg finance
Unlock the folder named "finance" and allow changes to all the contents:
$ chflags -R nouchg finance
Make the folder ~/Library visible (this was the default setting prior to OS X Lion).
$ chflags nohidden ~/Library
An alternative method to view the library is to use the 'Go' drop down menu in Finder and hold down the option key.
Hide the folder ~/Library from finder:
$ chflags hidden ~/Library
Make the file MyLogs.txt append-only:
$ chflags uappnd MyLogs.txt
Unlock your Documents directory and everything in it:
$ chflags -R nouchg ~/Documents
Warning: Please be aware that this method will stop ALL scheduled PM wake events from running which will effect features like Find My Mac so do not use it if you use these features or have planned scheduled events that need to run while the system is sleeping such as scheduled backups, email collection ..etc as the system will not wake up to execute them.
Since applying the above method i've not seen any scheduled PM wake events waking the system up while it is sleeping, so it appears that this method is working as expected. I will continue to monitor how well the method works over the next week or so and will update this post with more information if needed.
Update 22 Jan 2023
Since implementing this at the end of November 2022, the method continues to work perfectly with no Scheduled PM wakes or Dark Wakes in the last two weeks :-
Code:
jay@WK-2-MACOS ~ % pmset -g stats
Sleep Count:10
Dark Wake Count:0
User Wake Count:9
[HR][/HR][B]Update 1st Aug 2023[/B]
I can confirm that the method continues to work after updating Ventura to version 13.5 with no need to unapply the fix prior to the update or reapply the fix after the update, the same has been true for all previous MacOS Ventura updates.
[HR][/HR][B]Update 1st Nov 2023[/B]
I can confirm that the method continues to work after updating to MacOS Sonoma with no need to unapply the fix prior to the update or reapply the fix after the update.
[HR][/HR]
Despite the fact that the [ICODE]tcpkeepalive[/ICODE] appears to still work on systems using a Laptop SMBIOS, i have also implemented this method on my Kaby Lake based laptop Hack, I guess at this point I just don't trust Apple to not interfere with system sleep so for me, it made sense to do it on my laptop as well.
[B]Side Effects of the Method[/B]
After implementing the above i've noticed the appearance of new file called [ICODE]com.apple.AutoWake.plist-new[/ICODE] in the [ICODE]/Library/Preferences/SystemConfiguration/[/ICODE] folder that appears to be updated with a single wake event scheduled for +24 hours from when the system was last put to sleep (WTF Apple ?). The fact that the system has created a new file is not unexpected as MacOs has a built-in, fall back system of creating alternate versions of files if the primary file is not accessible. However since we have only stopped the system from writing to [ICODE]com.apple.AutoWake.plist[/ICODE] (but it is still able to read from it) the system is still using the primary file which is always empty as such no scheduled PM events are running or being listed in [B]System Information -> Power[/B] and by the Terminal command [ICODE]pmset -g sched[/ICODE].
[B]Final Thoughts[/B]
I think that the issue of these unwanted/extra wake events will get more and more attention as more users update to Ventura and i suspect that it will cause more and more people to report it as an issue to Apple support to the point that they will have to address it in someway and either re-enable the non functional [ICODE]pmset tcpkeepalive[/ICODE] command or add some sort on enable/disable feature to Ventura's System Settings.
I hope this post helps those of of you who are wondering just what the hell is going on with Ventura and these random (scheduled) PM wake events and that the above workaround helps some of you to manage it.
Cheers
Jay
Last edited:
