Parallels very slow too start - not the VM, just the Parallels UI

A

AveryS

Bit poster
I have an issue that recently started where launching the Parallels 13 Desktop is incredibly slow - like 5 minutes before the first window actually opens up. This is NOT waiting on a VM to launch. Once the desktop is actually open and I can choose between my VM's that I want to launch, performance is great. Performance in the VM is perfect. Shutting down the VM is great. No issues.

It's only the actual launch of the Desktop App itself. I'm on the latest patch of Parallels Desktop and MacOS High Sierra on a 2018 MBPro 15". The system had started doing this before I migrated to the 2018 laptop (was on a 2017 MBPro when the issue first started), but once I migrated, the problem went away. However, in the last week, launching has started being slow again.

Has anyone else seen this behavior?
 
For data, it appears like the prl_ls_users process is the one that is hanging. I did a ps over 1 sec intervals to see what was happening. Nothing changes on the system for about 5 minutes other than the prl_ls_users process (pid=89191) continues to gain time (see the attached output). At around 4:32PM you can see that both that process and pid=89191 (inittool) both exit and restart as new processes (pid=90401 and 90402 respectively).

Once that happens, things wake up and the system starts pretty quickly.
 

Attachments

Last edited:
Is your Mac connected to Active Directory or LDAP or something like this? This is pretty possible that Parallels Desktop may hang on enumerating local users on the system because of slow answers from remote directory service.
 
Good call. It's definitely related to the network. If I disconnect the network completely before starting Parallels, it comes right up. Similarly if I interrupt the network connection once starting, it hangs until the interruption, then immediately starts up when it detects the interruption. In fact, even just unplugging the wired network to force a failover to wireless is enough of an interruption to cause it to immediately start up - it doesn't see the interruption and just pick up again on the wireless. Is the data that it is pulling even needed? it doesn't seem to interfere with normal operations.

This seems very odd to me as performance for everything else that I do is pretty good - there are no major interruptions (I won't claim that there are ZERO performance issues however). but generally queries to the LDAP server respond very quickly. There seems like there may be something else going on under the covers here.
 
We may check if the problem does really relate to users enumerating. Run command in terminal:
$ dscl . list /Users
- if it lists users "quickly" the problem is somewhere else. If it "hangs like Parallels Desktop" - obviously the issue goes to directory service.

But nevertheless if the latter case, with slow directory service, our product should not hang. This is our bug we need to fix.
 
($)time dscl . list /Users
.... (about 95 users)
real 0m0.102s
user 0m0.019s
sys 0m0.055s

Doesn't appear to be the directory service. I also started Parallels immediately after the dscl and got the same behavior - hanging until I turned off wifi to force an interrupt.
 
Last edited:
AveryS said:
($)time dscl . list /Users
.... (about 95 users)
real 0m0.102s
user 0m0.019s
sys 0m0.055s

Doesn't appear to be the directory service. I also started Parallels immediately after the dscl and got the same behavior - hanging until I turned off wifi to force an interrupt.
Click to expand...

Ahh, sorry. My fault: this command lists only local users, it doesn't list directory users :-( Proper command should look like
$ dscl /LDAPv3/${your_ldap_srv_ip} list /Users
- but exact command depends on your system configuration.
 
That is it... doing it against the full directory took 5+ minutes, but it got cut off at 20k entries (out of .5mil or so). Running it multiple times improved so it probably took advantage of a cache somewhere.

why would you need to list all Users in the entire corporate directory to launch Parallels though? That seems very unnecessary.
 
Not fixed in v14. Tried it yesterday. It may be slightly improved but that's anecdotal.

The work around to turn off the network before starting Parallels does work (although inconvenient and a pain in the a**e).
 
AveryS said:
Not fixed in v14. Tried it yesterday. It may be slightly improved but that's anecdotal.

The work around to turn off the network before starting Parallels does work (although inconvenient and a pain in the a**e).
Click to expand...
Update: Installed v14. As you said, not better.

The network thing is good to know, but it's super inconvenient, especially if I'm on my VPN at work.
 
Same problem here (macOS 10.13.3, Parallels Desktop 14.0.0 (45124)): it can take 1-2 minutes before the first window appears, when launcing Parallels. I checked the Activity Monitor during Parallels launch: process "opendirectoryd" starts eating 80-100% of my processing power the second Parallels starts up, and calms down when the UI finally wakes up and shows the main window.

I also work in a large corporate network, and if I disconnect the network before launching Parallels, the problem disappears. I would really like to know, why does Parallels browse our LDAP when starting....? Please fix this: it's both annoying and extremely suspicious.
 
Our security team is reviewing to see if it should be banned for use on corporate laptops. :-(

While I appreciate the help in identifying the issue, some sort of response such as "yep... we get it... we are prioritizing a fix now" or SOMETHING would be helpful here.

Thanks!
 
Last edited:
I have opened a request with support for this, and they rolled into another existing request for the same thing. So they know this is an issue, but I'm not hearing anything else about it.
 
This just started for me as well. Launching Parallels 13 is suddenly very slow. Not referring to any VM, but simply to get to the Parallels Control Center. Running Parallels 13.3.2 and High Sierra 10.13.6.
 
I have been experiencing the same issue for the last six months. It's been so bad that I simply don't close Parallels Desktop on my Mac now. Fortunately, I've found a simple work around.
Shutdown your VM and close Parallels.
Go to your Application folder and right click on Parallels Desktop and select "Show Package Contents".
Under contents, expand the MacOS folder.
Rename the file "prl_ls_users" to something else.

Parallels should be able to start normally now. Not sure if this breaks anything on the network side but it appears ok on my system.
 
You must log in or register to reply here.
Back
Top