Contribute
Register

<< Solved >> Process "com.apple.parsec-fbf.flush" on Catalina 10.15.2 prevents system from sleeping automatically.

Status
Not open for further replies.
This issue is discussed here too:


Terminal command below is the most appropriate solution for this bug currently.

Code:
launchctl unload -w /System/Library/LaunchAgents/com.apple.parsec-fbf.plist
 
Last edited:
I don't have any sleep problems with Catalina 10.15.2. 10.15.2 has been rock solid.

I have Siri and Messages enabled and working. I also have SIP enabled.

Good to hear!

Anyway it seems to be very specific behaviour.

Actually comp goes into idle sleep on first time, but on second time, sleep is prevented by this background task which is revived by wake. Before first wake this task is not running.

Software sleep works without issues.
 
Software sleep works without issues.

For me, it doesn't matter if I let it go to sleep on its own or if I invoke it by clicking on sleep. There are no sleep/wake issues at all in Catalina.
 
For me, it doesn't matter if I let it go to sleep on its own or if I invoke it by clicking on sleep. There are no sleep/wake issues at all in Catalina.

Thats great that you do not have this issue. Sadly it doesn’t help much these who are affected by this issue. Interesting question is what causes this background task to run and prevent idle sleep after wake. This task is not running after reboot and logging in. Somehow it’s revived by wake.

According to my tests it affects only idle sleep after the first wake as this background task is revived on first wake. I had this issue on both comps listed below on my builds banner. Both have macOS 10.15.2. Z170 was upgraded from High Sierra directly to the Catalina 10.15.2. Before upgrade there ere no any issues with sleep on Z170. Even Power Nap worked fine.
 
Thats great that you do not have this issue. Sadly it doesn’t help much these who are affected by this issue. Interesting question is what causes this background task to run and prevent idle sleep after wake. This task is not running after reboot and logging in. Somehow it’s revived by wake.

According to my tests it affects only idle sleep after the first wake as this background task is revived on first wake. I had this issue on both comps listed below on my builds banner. Both have macOS 10.15.2. Z170 was upgraded from High Sierra directly to the Catalina 10.15.2. Before upgrade there ere no any issues with sleep on Z170. Even Power Nap worked fine.

I would suggest testing on a clean install with no other software installed.
 
I would suggest testing on a clean install with no other software installed.

Thank you for suggestions but my Z390 is already almost blank, fresh install.

Also the best solution is to figure out what actually might cause it, so this could be easily fixed. It’s obvious that this is not single installation issue and specific especiallly to 10.15.2.
 
Thank you for suggestions but my Z390 is already almost blank, fresh install.

Also the best solution is to figure out what actually might cause it, so this could be easily fixed. It’s obvious that this is not single installation issue and specific especiallly to 10.15.2.

It's not a 10.15.2 issue since not everyone is affected by it. So, it has to be some other software and/or hackintosh configuration issue.
 
It's not a 10.15.2 issue since not everyone is affected by it. So, it has to be some other software and/or hackintosh configuration issue.

There is no any reports about this issue on other macOS versions and this was introduued on 10.15.2. Can you proof otherwise?

Also, this task isn't exclusive to Siri, but anything that uses/needs suggestions (Spotlight, Message, Safari, etc.).

There are plenty of chances on 10.15.2:

The macOS Catalina 10.15.2 update improves the stability, reliability and performance of your Mac and is recommended for all users.

This update adds the following features:

Apple News
• New layout for Apple News+ stories from The Wall Street Journal and other leading newspapers

Stocks
• Get links to related stories or more stories from the same publication at the end of an article
• “Breaking” and “Developing” labels for Top Stories
• Stories from Apple News are now available in Canada in English and French

This update also includes the following bug fixes and improvements:

Music
• Restores the column browser view for managing the music library
• Resolves an issue that may prevent album artwork from appearing
• Fixes an issue that may reset music equalizer settings during playback

iTunes Remote
• Adds support for using an iPhone or iPad to remotely control the Music and TV apps on a Mac

Photos
• Resolves an issue that may cause some .AVI and .MP4 files to appear as unsupported
• Fixes an issue that prevents newly created folders from appearing in Albums view
• Addresses an issue where manually sorted images in an album may be printed or exported out of order
• Fixes an issue that prevents the zoom-to-crop tool from working in a print preview

Mail
• Addresses an issue that may cause Mail Preferences to open with a blank window
• Resolves an issue that may prevent using undo from retrieving deleted mail

Other
• Improves the reliability of syncing books and audiobooks to your iPad or iPhone through Finder
• Fixes an issue where reminders may be out of order in the Today smart list in the Reminders app
• Resolves an issue that may cause slow typing performance in the Notes app


For more detailed information about this update, please visit: https://support.apple.com/kb/HT210642
For detailed information about the security content of this update, please visit: https://support.apple.com/kb/HT20122
 
Can you proof otherwise?

Screen Shot 2020-01-02 at 10.46.38 PM.png


Screen Shot 2020-01-02 at 10.47.52 PM.png
 
It's not a 10.15.2 issue since not everyone is affected by it.

This was your statement! I’m telling that this far this issue is first introduced on MacOS 10.15.2 only and there is no any proof this far that this happens on any older MacOS versions. The fact that this doesn’t occur for every 10.15.2 users comp doesn’t mean that this is not 10.15.2 issue. There are lot of changes in 10.15.2 as I listed above. Can you proof that it happens on other MacOS versions? So let’s stick on actual fact instead of opinions/guesses.

Current facts are:
  • First introduced on macOS 10.15.2
  • macOS 10.15.2 comes with new version of parsec-fbf agent (see details below).
  • macOS 10.15.2 comes also with new version of XNU 6153.61.1. macOS 10.15.1 comes with XNU 6153.41.3.
  • macOS 10.15.2 and macOS 10.15.0 share the same com.apple.parsec-fbf.plist launch agent file.
  • Occurs probably only on some macOS 10.15.2 installations, probably not every macOS 10.15.2 comp is affected.
  • Both genuine Mac's and Hack's are affected.
  • Not reported on any older macOS versions this far.
  • Background task preventing Idle Sleep is revived with Wake after Sleep
  • Task is not preventing sleep on freshly booted OS before first Sleep and Wake usually.
  • Only Idle Sleep is affected, Software Sleep works fine.
  • Task can be killed via Activity Monitor, but it revives immediately again and still prevents the Idle Sleep
  • Doesn’t prevent display to go into sleep.
  • Background task is called by launchd as agent.
As macOS 10.15.2 comes with new version of XNU 6153.61.1, this might be also kernel level issue, that affects only certain Hacks, which share some common configuration pattern.

The primary question is why it prevents the Idle Sleep only and why the Software Sleep isn’t affected? Why it is called with Wake?

Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep.

CoreParsec.framework is part of Siri

/System/Library/PrivateFrameworks/CoreParsec.framework/Versions/Current/Resources/Info.plist

  • Bundle identifier: com.apple.siri.parsec.CoreParsec
  • Privacy - Location Usage Description: Spotlight, Messages, Lookup & Safari Suggestions use your location to provide more accurate local results.
NAME
parsec-fbf -- Support daemon for Siri Search analytics

DESCRIPTION
parsec-fbf is responsible for periodic flush and upload of Siri Search analytics data.
There are no configuration options for parsec-fbf. Users should not run parsec-fbf manually.

Genuine Mac's are affected too!

Examination of authentic Apple MacMini (Catalina 10.15.2) reveals that the same background task is running on this comp too:

Code:
pid 356(UserEventAgent): [0x00000129000b823e] 00:18:30 BackgroundTask named: "com.apple.parsec-fbf.flush"

Idle Sleep on genuine Macs is affected also by the same cause, parsec-fbf is preventing Idle Sleep on genuine Mac's too. Software sleep works fine.

Info about com.apple.parsec-fbf.plist:

finder-info-com.apple.parsec-fbf.plist.jpg


content-of-com.apple.parsec-fbf.plist.jpg


File is in binary format, XML conversion:

Code:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>EnablePressuredExit</key>
    <true/>
    <key>EnableTransactions</key>
    <true/>
    <key>Label</key>
    <string>com.apple.parsec-fbf</string>
    <key>LaunchEvents</key>
    <dict>
        <key>com.apple.xpc.activity</key>
        <dict>
            <key>com.apple.parsec-fbf.flush</key>
            <dict>
                <key>AllowBattery</key>
                <false/>
                <key>Interval</key>
                <real>3600</real>
                <key>Priority</key>
                <string>Maintenance</string>
            </dict>
        </dict>
    </dict>
    <key>MachServices</key>
    <dict>
        <key>com.apple.parsec-fbf</key>
        <true/>
    </dict>
    <key>POSIXSpawnType</key>
    <string>Adaptive</string>
    <key>ProcessType</key>
    <string>Background</string>
    <key>Program</key>
    <string>/System/Library/PrivateFrameworks/CoreParsec.framework/parsec-fbf</string>
</dict>
</plist>

Process is disabled if comp runs on battery power.

Apple has made changes in parsec-fbf on 10.15.2

Comparing com.apple.parsec-fbf.plist used on 10.15.2 and on 10.15.0 reveals that these files are identical. So there is no changes in com.apple.parsec-fbf.plist file itself made on macOS 10.15.2. But changes are made in parsec-fbf.

Comparison of parsec-fbf on different Catalina versions

Code:
md5 10.15.0/parsec-fbf
MD5 (10.15.0/parsec-fbf) = e20c200814c4ce5fcd3ae5af7394e1d1

md5 10.15.2/parsec-fbf
MD5 (10.15.2/parsec-fbf) = a97bb8b8227c063289a6e0d43582b10f

Code:
Left file: ./parsec-fbf versions/10.15.0/parsec-fbf
Right file: ./parsec-fbf versions/10.15.2/parsec-fbf
1443572 same byte(s)
150586 left orphan byte(s)
211226 right orphan byte(s)
148034 difference byte(s)

It's obvious that Apple has made changes to parsec-fbf on macOS 10.15.2, which probably explains why issue with Idle Sleep was first reported after upgrade's 10.15.2. Comps with macOS 10.15.1 and older are not affected probably. Will update the post when I get a copy of 10.15.1 parsec-fbf. I suspect that 10.15.0 and 10.15.1 share the same parsec-fbf.

Sleep behaviour on MacMini

On MacMini I can trace at least 3 different sleep modes:
  • Idle Sleep
  • Software sleep
  • Maintenance sleep
When I choose from macOS menu Sleep then comp goes into Software sleep, but if setting Wake for Ethernet is enabled, it switches form Software sleep immediately into Maintenance sleep. if Wake for Ethernet is disabled, then switch to the Maintenance sleep doesn't happen.

The parsec-fbf agent prevents Idle sleep on MacMini too on macOS 10.15.2. Screens switches to sleep but no actual sleep. But its's impossible to see the difference just with an eye, only via terminal command pmset -g log|grep -e " Sleep " -e " Wake " you can see that comp didn't went into actual sleep, only screen was put on sleep.

Solution

To enable Idle Sleep on affected comps quite simple terminal command can be used.

Code:
launchctl unload -w /System/Library/LaunchAgents/com.apple.parsec-fbf.plist

As parsec-fbf sends analytical data to Apple and flushes which is sent from local machine, then probably there is no any serious drawbacks on disabling parsec.fbf agent, except that data collected by Siri is not flushed. Data is collected in users Cashes into com.apple.parsecd folder.

Data can be flushed manually if needed:

Code:
cd ~/Library/Caches
rm -R com.apple.parsecd

Investigation of ~/Library/Caches/com.apple.parsecd shows that not only Siri searches data is collected but Safari as well.
 

Attachments

  • com.apple.parsec-fbf.plist
    460 bytes · Views: 131
Last edited:
Status
Not open for further replies.
Back
Top