com.apple.apfsd.wbc_drain

iMac (Retina 5K, 27 pouces, 2019) 10.15.4 - fusion drive (apple built-in)

I have reproduce it on a completely clean install. I added a volume and did install Catalina on it and boot from it.

I did not install anything, just created an account, and an issue is there.

So this is definitively a Catalina issue (I never see on Mojave).

It is related to fusion drive, this does not happen on my MBP that has a SSD, a task will appear after some time or after the 1st sleep/wake sequence.

This task is started by apfsd that starts a user agent that starts com.apple.apfsd/wbc_drain that will never stop and prevent the sleep.

I'm wondering if Apple take care of this as you can find many people having the issue.

I find a workaround, not very clean but this is the only way out, and it will not persist across boot.

The workaround consist in killing this background task by killing the UserEventAgent that supports it.

It turns that it need to be killed several times as it restart

in zsh you can copy past this. This will hide the issue until reboot or may be after sometimes the OS will restart this endless task.

until [ -z $(ps -ef | grep UserEventAgent | grep System | awk '{print $2}') ]
do
ps -ef | grep UserEventAgent | grep System | awk '{print $2}' | xargs sudo kill -9
done

It can be true as people are chosing SSD.

however my iMac is recent and was sold with an Fusion drive.

I will contact Apple Care.

I know they won’t do anything but this a way to tell the problem exists.

may be a class action in US would help but I’m quite sure most owners simply don’t notice this issue.

This does not exist, the class action, in my country.

Not that for this fix to work, the OS need to have already started wbc_drain background task.

This is not happening right after boot.

From my experience, it requires about 10 mns after boot or the Mac to to have gone one time in sleep.

one way is to check for the background task before executing the previous line to see if the background task is running

% pmset -g assertions | grep wbc_drain

if you have such result

pid 217(UserEventAgent): [0x000001c4000b838f] 00:04:36 BackgroundTask named: "com.apple.apfsd.wbc_drain"  

then the task is running and you can executes the line.

so te previous suggestion can be improved

until [  $(pmset -g assertions | grep wbc_drain | wc -l) -gt 0 ] 
do
done
until [ -z $(ps -ef | grep UserEventAgent | grep System | awk '{print $2}') ]
do
ps -ef | grep UserEventAgent | grep System | awk '{print $2}' | xargs sudo kill -9
done

still happening on 10/15/4 supplemental update '10.15.4 (19E287)'

Also noticed that the UserEventAgent that runs the BackgroundTask come.apple.apfsd.wc_drain has its flag 'Preventing Sleep' set to 'No' while it prevent sleep

P.S. A report have been generated indeed using feedback assistant

Indeed it looks like I have tested too fast the 10.5.4 supplemental update '10.15.4 (19E287)'

And I choose to use my decaffeinate command as on previous release.

Since 8 days I decide to more thorroughlly test it.

here are the results

$ uptime
10:55  up 8 days, 17 mins, 10 users, load averages: 1,81 1,63 1,50
$ pmset -g stats
Sleep Count:93
Dark Wake Count:84
User Wake Count:45

Sleep Count represents the real deep sleeps, I can confirm it from an end user prospective, the end-user caused wake-ups when the Mac is deep sleeping are noticeably longer than when it is not deep sleeping.

So it seems the problem is fixed.

Of course, my iMac deep sleeps less that when I use my decaffeinate command (that kills com.apple.apfsd.wbc_drain), however this task is there for something, I assume some maintenance routine related to fusion drive, will probably never know.

So I prefer having this task running now that my fusion drive equipped iMac is deep sleeping.

I also investigate the full log where we can see when this task prevented the idle as far as I can understand.

$ pmset -g log | grep wbc_drain | wc -l
     637
$ pmset -g log | grep wbc_drain | grep PrevIdle | wc -l
      70

So 11% of the time this task is running, it seems to prevent idleness.

Sure, as stated in my previous post, with 10.15.4 supplemental update the issue did vanish.

So it would means it is back on 10.15.5 ?!

see my state below on 10.15.4

$ uptime
11:28  up 15 days, 13:07, 11 users, load averages: 0.87 0.99 1.11
$ pmset -g stats
Sleep Count:121
Dark Wake Count:104
User Wake Count:53
$

And regularly I can see that my iMac is slower to wake-up as it is in sleep.

In regards of statistic I'm more at 15% of sleep prevented by wbc_drain

$ pmset -g log | grep wbc_drain | wc -l
     635
$ pmset -g log | grep wbc_drain | grep PrevIdle | wc -l
      98

I hope the problem is not back on 10.15.5, I have not yet upgraded.

Still seeing this issue on iMac 5k 2017 10.15.5 2TB Fusion drive.

$ pmset -g log | grep PrevIdle | grep wbc_drain

2020-05-31 19:20:58 +0100 Assertions          PID 95(UserEventAgent) Summary BackgroundTask "com.apple.apfsd.wbc_drain" 74:18:23  id:0x0xb0000821a [System: PrevIdle DeclUser BGTask kDisp]          

I found in the system files, in the launch demons folder, this preference com.apple.apfsd.plist which in my opinion is the cause of the problem: I tried to delete the file but it is not possible, it is protected ... According to you it can be solved the bug if you delete this file?

https://discussions.apple.com/thread/250933408?answerId=251818736022#251818736022

Do you have an Apple fusion drive (HDD + SSD Apple)? Or a fusion drive with a SSD you installed yourself?

I have an Intel SSD: INTEL SSDSC2BW180A4 

I was not able to disable trim... I disabled SIP, then "sudo trimforce disable", then reboot but after reboot trim remains enabled as per the system report.