The above is based on the assumption that the laptop shouldn't suspend when an external monitor (or docking station) is used.  This is a change from RHEL6 where it suspends even in this case but I suppose it is a deliberate change (please correct me if I'm wrong).

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Can you please switch systemd loging to debug "kill -56 1" or add "debug" to kernel cmdline, reproduce the issue and post here output of journalctl -b.

Also please switch on debug for systemd-logind. Add drop-in configuration file debug.conf with following content : 

[Service]
Environment="SYSTEMD_LOG_LEVEL=debug"

under /etc/systemd/system/systemd-logind.service.d/ and reload systemd and restart logind.

gnome-settings-deamon is creating an handle-lid-switch inhibitor when multiple monitors are attached, but it is not releasing it after the laptop is taken out of the dock.

     Who: lnykryn (UID 1000/lnykryn, PID 1604/gnome-settings-)
    What: handle-lid-switch
     Why: Multiple displays attached
    Mode: block

Can you please run:
/usr/libexec/gnome-settings-daemon --replace --debug
reproduce the problem and send the output?

Also, what's the output of "xrandr -q --props" after unplugging the dock?

Created attachment 886544 [details]
g-s-d debug

Created attachment 886545 [details]
xrandr -q --prop

Attached are the requested logs.

What I did:
1. Placed my laptop in the dock, disabled the integrated display and enabled an external one
2. Replaced the g-s-d instance by running:
/usr/libexec/gnome-settings-daemon --replace --debug
3. Unplugged the laptop
4. Closed the lid

How long did you wait for the laptop to suspend. Near the end, we can see that you closed the lid, which starts a timeout.

The log:
(gnome-settings-daemon:3742): power-plugin-DEBUG: up changed: lid is now closed
(gnome-settings-daemon:3742): power-plugin-DEBUG: restarting lid close safety timer
(gnome-settings-daemon:3742): power-plugin-DEBUG: setting up lid close safety timer

The code:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c?h=gnome-3-8#n2177

30 seconds later, after the timeout, you'll get either "no external monitors for a while; uninhibiting lid close" or "external monitor still there; trying again later":
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/power/gsd-power-manager.c?h=gnome-3-8#n2151

Instead, I see:
(gnome-settings-daemon:3742): power-plugin-DEBUG: up changed: lid is now open

Which means that you opened the lid before the 30 seconds were up. The 30 seconds are there for you to be able to open the lid without the laptop having suspended. It's actually a feature.

Am I correct in thinking that you didn't wait 30 seconds?

Michal, is this something you're just seeing with a single laptop/dock combination or specific to a single test machine ? (assuming it is not simple a case of 'didn't wait long enough')

Bastien, Matthias, you're right.  I didn't wait for 30 seconds; I repeated the process today and found out that it really *suspends* after 30 seconds.  While I agree with this feature being useful, it's not something that one would expect.  From an ordinary user's point of view, if I closed the lid and the laptop didn't suspend right away (let's say +- 10 seconds) I would simply assume that it's not going to (and would just reopen the lid and suspend the machine manually if I was in a hurry.)

However, to make it a little more complicated:  If I close the lid in rapid succession after undocking (i.e. before g-s-d has a chance to get notified about the layout change, which is noticeable as a desktop refresh) it won't suspend at all, not even after the 30 secs.  This may be just a nature of the whole process and not a bug, though.

Do you think the latter deserves a separate bug report?

Just to add:  Any subsequent lid close (after that first one since undocking) makes the computer suspend without the delay.

Created attachment 889230 [details]
g-s-d debug - no suspend after 30s

Attaching the g-s-d output after reproducing the case when it never suspends (well, I waited for 2 minutes :) ), see Comment 13 for details.

(In reply to Michal Domonkos from comment #13)
> Bastien, Matthias, you're right.  I didn't wait for 30 seconds; I repeated
> the process today and found out that it really *suspends* after 30 seconds. 
> While I agree with this feature being useful, it's not something that one
> would expect.  From an ordinary user's point of view, if I closed the lid
> and the laptop didn't suspend right away (let's say +- 10 seconds) I would
> simply assume that it's not going to (and would just reopen the lid and
> suspend the machine manually if I was in a hurry.)
> 
> However, to make it a little more complicated:  If I close the lid in rapid
> succession after undocking (i.e. before g-s-d has a chance to get notified
> about the layout change, which is noticeable as a desktop refresh) it won't
> suspend at all, not even after the 30 secs.  This may be just a nature of
> the whole process and not a bug, though.
> 
> Do you think the latter deserves a separate bug report?

It's 30 seconds after the last one of lid opening/closing and the screen configuration changing. See the repeated "setting up lid close safety timer" messages. As I mentioned, we should see either the:
no external monitors for a while; uninhibiting lid close
message, or this one:
external monitor still there; trying again later

We don't see either, which leads me to believe that you didn't wait long enough.

I'm not arguing about the 30s delay :)  I already confirmed your suspicion that I didn't wait for 30s originally.  As I said I tried to reproduce today but waited for 30s this time and it really did suspend then.  I even checked the log and saw the "no external monitors for a while; uninhibiting lid close" message.

What I'm not sure about now is whether it is expected that the machine doesn't suspend after those 30s in case you close the lid too soon after unplugging external monitors (i.e. within ~3 seconds)?

(In reply to Michal Domonkos from comment #17)
> What I'm not sure about now is whether it is expected that the machine
> doesn't suspend after those 30s in case you close the lid too soon after
> unplugging external monitors (i.e. within ~3 seconds)?

It's supposed to suspend, and I was asking about whether you waited long enough for *that* use. When you unplug monitors, and close the lid in quick succession, two things could occur:
- The monitor being unplugged is detected first, we'll set up a timeout, and inhibit_lid_switch_timer_cb() will be triggered 30 seconds later (giving one of those 2 messages I was mentioning)
- The lid being closed will be triggered first, showing the "up changed: lid is now ..." message, a timeout will be setup, again to check for the status of the machine in 30 seconds.

But, I can see a lot of "Screen configuration changed" messages at the bottom of your logs, meaning that the timer will be restarted (again) for each of those events:
(gnome-settings-daemon:7098): wacom-plugin-DEBUG: Screen configuration changed
(gnome-settings-daemon:7098): power-plugin-DEBUG: restarting lid close safety timer
(gnome-settings-daemon:7098): power-plugin-DEBUG: setting up lid close safety timer
<bis repetita>

So, did you wait long enough in your latest test?

But the point is that it doesn't suspend in the said case :)

What do you mean by "long enough"?  I was waiting even 3 minutes (measured with a stopwatch in my phone) without the laptop going to sleep.

To sum it up, this is the failing scenario I was talking about:

1. Have the laptop docked, lid open
2. Undock the laptop
3. Close the lid right away
4. Wait for suspend

Result:  After 30 seconds the laptop doesn't suspend.  Like I said above, I'm actually waiting for 3 minutes in total and the laptop is still running (as indicated by a LED on the top of the lid).

While playing with this I've found another failing scenario:

1. Have the laptop docked, lid *closed*
2. Undock the laptop
4. Wait for suspend

Result:  Same as the previous one, no suspend after 30 seconds or more.

-------------

Success scenario:

1. Have the laptop docked, lid open
2. Undock the laptop
3. Wait for a few seconds until the monitor config change is detected (screen refreshes).  Usually takes around 3 to 4 seconds
4. Close the lid
5. Wait for suspend

Result:  After 30 seconds the laptop suspends.

-------------

According to what you are saying about the events in the log, it seems like something is triggering the "Screen configuration changed" events but I have no idea what that might be since I'm not doing anything with the laptop once undocked and lid closed.

To make sure it's not something HW or installation specific I'll test a different laptop tomorrow or so and will report here the findings.

(In reply to Michal Domonkos from comment #19)
<snip> 

> 1. Have the laptop docked, lid *closed*
> 2. Undock the laptop
> 4. Wait for suspend

<snip>

this works for me for X230 ivy bridge laptop. I have to wait 30 seconds but it finally gets to sleep.

Can you please test with this build?
https://brewweb.devel.redhat.com/taskinfo?taskID=7385368

Also make sure to capture the debug output again.

Ugh, this build actually segfaults for me as soon as I undock, here's the backtrace:

#0  0x00007ffff73b2a53 in diff_outputs_and_emit_signals (old=0x728ee0, new=0xaf24d0, new=0xaf24d0) at gnome-rr.c:554
#1  screen_update (screen=0x7dd2e0, force_callback=force_callback@entry=1, needs_reprobe=needs_reprobe@entry=0, error=error@entry=0x0) at gnome-rr.c:622
#2  0x00007ffff73b2c95 in screen_on_event (xevent=<optimized out>, event=<optimized out>, data=<optimized out>) at gnome-rr.c:654
#3  0x00007ffff6a81ea1 in gdk_event_apply_filters (xevent=xevent@entry=0x7fffffffdd60, event=event@entry=0x88c4c0, window=window@entry=0x65b050) at gdkeventsource.c:81
#4  0x00007ffff6a82153 in gdk_event_source_translate_event (xevent=0x7fffffffdd60, event_source=0x653210) at gdkeventsource.c:202
#5  _gdk_x11_display_queue_events (display=0x652020) at gdkeventsource.c:338
#6  0x00007ffff6a56188 in gdk_display_get_event (display=display@entry=0x652020) at gdkdisplay.c:313
#7  0x00007ffff6a81f22 in gdk_event_source_dispatch (source=source@entry=0x653210, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:360
#8  0x00007ffff53e0ac6 in g_main_dispatch (context=0x6405b0) at gmain.c:3058
#9  g_main_context_dispatch (context=context@entry=0x6405b0) at gmain.c:3634
#10 0x00007ffff53e0e48 in g_main_context_iterate (context=0x6405b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3705
#11 0x00007ffff53e125a in g_main_loop_run (loop=0x729b50) at gmain.c:3899
#12 0x00007ffff6e4f0ed in gtk_main () at gtkmain.c:1156
#13 0x0000000000403847 in main (argc=1, argv=0x7fffffffe0e8) at main.c:479

Created attachment 889628 [details]
g-s-d debug (build bz1090555) - undock with lid already closed

Probably irrelevant due to the segfault but attaching it anyway.

Summary of my testing to date:

1. Undock with lid open, then close (within ~3 seconds)
    * X230 and HP EliteBook both suspend after 30s
    * T520 keeps running even after 30s
2. Undock with lid open, then close (with at least ~3 seconds in between)
    * all laptops suspend after 30s
3. Undock with lid closed
    * X230 suspends after 30s
    * T520 and HP EliteBook both keep running even after 30s

Please test this build:

https://brewweb.devel.redhat.com/taskinfo?taskID=7393974

It fixes the problem here on a T520.

(In reply to Rui Matos from comment #26)
> Please test this build:
> 
> https://brewweb.devel.redhat.com/taskinfo?taskID=7393974
> 
> It fixes the problem here on a T520.

OK, this is the situation with the new build tested on my T520:

1. Undock with lid open, then close (within ~3 seconds)
    * suspends after 30s
2. Undock with lid open, then close (with at least ~3 seconds in between)
    * suspends after 30s
3. Undock with lid closed
    * suspends after 30s

However, case 3 will only pass when the following conditions are met:
* Current g-s-d instance was launched while the lid was open
* It's the first suspend with the current g-s-d instance, i.e. any repeated suspend will fail again until you re-launch the g-s-d or open (and then close again) the lid.

IOW, there really is an improvement (as case 3 never passed with the older build) but it's still not 100%.

(In reply to Michal Domonkos from comment #27)
> OK, this is the situation with the new build tested on my T520:
> 
> 1. Undock with lid open, then close (within ~3 seconds)
>     * suspends after 30s
> 2. Undock with lid open, then close (with at least ~3 seconds in between)
>     * suspends after 30s
> 3. Undock with lid closed
>     * suspends after 30s

Thanks for testing. The patch used in that build is a pretty simple fix to g-s-d's output detection:

diff --git a/plugins/power/gpm-common.c b/plugins/power/gpm-common.c
index b1ce32a..70e4591 100644
--- a/plugins/power/gpm-common.c
+++ b/plugins/power/gpm-common.c
@@ -1694,6 +1694,8 @@ randr_output_is_on (GnomeRROutput *output)
 {
         GnomeRRCrtc *crtc;
 
+        if (!gnome_rr_output_is_connected (output))
+                return FALSE;
         crtc = gnome_rr_output_get_crtc (output);
         if (!crtc)
                 return FALSE;


Note that this bug also exists in g-s-d's most recent branches. I don't think this check ever worked correctly before.

> However, case 3 will only pass when the following conditions are met:
> * Current g-s-d instance was launched while the lid was open
> * It's the first suspend with the current g-s-d instance, i.e. any repeated
> suspend will fail again until you re-launch the g-s-d or open (and then
> close again) the lid.

I investigated this and to me it seems like a systemd-logind bug:

g-s-d does not issue the suspend call directly, it simply lets logind suspend when the lid is closed by releasing logind's lid inhibitor. What happens on this case is that logind only polls the lid button state after it has seen one lid open event[1].

If the laptop resumes from suspend while the lid is closed, g-s-d takes the inhibitor as usual. If it sees the external monitor it holds the inhibitor and prevents suspension. Then, when it gets undocked, g-s-d releases the inhibitor, but logind isn't checking the lid state because there never was a lid open event and thus it doesn't suspend.

This should probably be evaluated by a systemd developer.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/login/logind-button.c?id=1434ae6fd49f8377b0ddbd4c675736e0d3226ea6#n158 - this is the v208 of the code, i.e. what's shipped in rhel7

Thanks for looking into that, Rui, now it pretty much makes sense.  I've just filed it against systemd as bug 1092905.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.