Occasionally when you leave computer running with Chrome web browser running, whether it’s Windows, macOS (Mac OS X) or Linux, or in Chromium PC, the computer fails to go into sleep (or hibernate if configured as such) automatically after a preset duration of time.
When troubleshooting the possible issues that may prevent the computer from sleeping or hibernating automatically, Chrome web browser appears to be the culprit that is holding back the computer from going into sleep automatically.
For example, when running various power management troubleshooting command to identify culprit suppressing the power management with commands such as “powercfg /requests” in Windows or “pmset -g assertions” in macOS, the following results may be returned:
[PROCESS] \Device\HarddiskVolume1\Program Files (x86)\Google\Chrome\Application\chrome.exe
WebRTC has active PeerConnections
pid 888(Google Chrome): [0x00088a8800012345] 00:00:10 NoIdleSleepAssertion named: “WebRTC has active PeerConnections”
/usr/lib64/chromium/chromium is currently suppressing power management: WebRTC has active peer connections
Normally, an audio stream may also be currently in use when WebRTC peer connections are opened. The issue can happen on Chromium operating system or Google Chrome web browser running in non-Chrome OS such as Windows, Linux and Mac OS X.
WebRTC is designed for real-time communication, with a direct audio and video connection between user endpoints. Some websites are not properly implementing the WebRTC technology, knowingly or unknowingly, especially when it’s relating to ad content delivery.
If you have just a few tabs opened, identifying the web page that makes the WebRTC peer connections is easy, where you can close the tab to see if the connections go away. However, if you have many tabs opened, it’s possibly hard to know for sure which tab has web page that run webRTC connections. You can view information about the web page URL and what specifically WebRTC does by visiting the following URL in Chrome or Chromium browser:
After identifying the URL (and hence the tab) which makes WebRTC calls, you have two options.
First method, and the easiest, is to just close the tab or leave the web page, which normally would close out and terminate any connections.
Second method is by blocking the website by adding the offending URL (can be through pattern or regular expression) to an ad blocking add-on. Alternatively, you can be more specific by just blocking WebSocket first-party cookies, which should prevent WebRTC connections from been established.