I have noticed that a) systemctl suspend does actually suspend, but it takes about 30 seconds. I'm on 18.04.1 with kernel 4.18.0-13-generic from the proposed PPA This is quite surprising, but good news. I don't know why this is working now. It works with either Chromium or Chrome open, with hangouts running. Because gnome uses systemctl suspend, this means that manual suspend from gnome shell is also working. I just suspended right now with a hangouts conversation in progress and a Zoom meeting started, and it succeeded.
Maybe the more recent kernel fixes it? b) pkexec systemctl -i suspend (run with root privileges) always works, but this is less suprising, since -i means ignore inhibitors. On Thu, 13 Dec 2018 at 12:16, ethanbrown <[email protected]> wrote: > I agree with W-barath-hotmail that this is a serious problem that needs > to be addressed. I believe on some occasions suspend fails even after > I've killed Chrome. > > Please increase the Importance ranking of this bug. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1600622 > > Title: > Screen doesn't lock or go to sleep when certain Chrome tabs are open > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions > -- Tim Richardson -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-session in Ubuntu. https://bugs.launchpad.net/bugs/1600622 Title: Screen doesn't lock or go to sleep when certain Chrome tabs are open Status in gnome-session package in Ubuntu: Confirmed Bug description: $ lsb_release -rd Description: Ubuntu 16.04 LTS Release: 16.04 $ apt-cache policy gnome-session-bin gnome-session-bin: Installed: 3.18.1.2-1ubuntu1.16.04.1 Candidate: 3.18.1.2-1ubuntu1.16.04.1 Version table: *** 3.18.1.2-1ubuntu1.16.04.1 500 500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.18.1.2-1ubuntu1 500 500 http://es.archive.ubuntu.com/ubuntu xenial/main amd64 Packages I'm using gnome-session-flashback What happens: The screen doesn't lock when having certain pages in Chrome tabs Expected: The screen should lock after the configured timeout in settings. I've been having this issue sice before 14.04, which I recently upgraded (fresh install) to 16.04. After fresh install, the screen would turn down and lock the computer after 10 minutes (or whatever time I setup). At one point it stopped working. The screen never shuts down unless I manually lock the session with CTRL-ALT-L. I've followed the steps in https://wiki.ubuntu.com/DebuggingScreenLocking#Debugging_procedure The culprit seems to be that Chrome issues some suspend inhibitions through dbus when doing certain operations. Many people find this problem when using Yahoo Mail. I can reproduce it with Odoo. I'm pretty sure that Chrome is doing something else of what i've found out. 1) Gnome screen saver works correctly. I can trigger it manually with: $ gnome-screensaver-command -a 2) Gnome screen saver never receives the "session idle" status callback. 3) When Chrome is not running, I can manually inhibit the idle status: $ gnome-session-inhibit --app-id test --reason "manual idle inhibit" --inhibit-only --inhibit idle:suspend Inhibiting until Ctrl+C is pressed... 4) I can query the inhibitors: $ dbus-send --print-reply --dest=org.gnome.SessionManager /org/gnome/SessionManager org.gnome.SessionManager.GetInhibitorsmethod return time=1468170482.066533 sender=:1.19 -> destination=:1.1315311 serial=1329103 reply_serial=2 array [ object path "/org/gnome/SessionManager/Inhibitor1686" ] $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetAppId ('test',) $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetReason ('manual idle inhibit',) $ gdbus call --session --dest org.gnome.SessionManager --object-path /org/gnome/SessionManager/Inhibitor1686 --method org.gnome.SessionManager.Inhibitor.GetFlags (uint32 12,) 12=4(suspend) + 8(idle) 5) When testing, I can inhibit for 70 seconds, idle timeout being 60 (1 minute). After these 70 seconds pass, the screen locks. 6) Regarding Chrome, this is the information I get when querying the inhibitor: GetAppId: ('/usr/bin/google-chrome-stable',) GetReason: ('Uploading data to 10.200.0.163',) GetFlags: (uint32 4,) The flags just inhibits suspend, not locking or entering powersaving mode. This inhibitor seems to stay for 10-15 seconds, then goes away for another 30-60 seconds. The screen NEVER locks when this tab is open. No matter the inhibitor is present or not. I'm not sure where to go on. If it's a Chrome bug it must be using other mechanisms to prevent the idle timeout. Any ideas on what to look for? Julian. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
