Adding this line to `/etc/systemd/logind.conf` will prevent the behavior:

    HandleLidSwitch=ignore

However now when I go into gnome-tweak-tool and change lid behavior on battery
and AC from "blank" to "suspend", it doesn't do actually suspend when I close
the lid.

More data:

╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  systemd-inhibit --list                                                    
                                                  127 ↵ 2012.10.31 20:50:40 CDT 
WHAT                                                     WHO                 
WHY                  MODE     UID    PID
handle-power-key:handle-suspend-key:handle-hibernate-key ting                
GNOME handlin...sses block   1000    776
sleep                                                    root                
inhibited            delay      0    309
handle-lid-switch                                        ting                
Multiple disp...ched block   1000    776

3 inhibitors listed.

╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  gsettings get org.gnome.settings-daemon.plugins.power lid-close-ac-action 
                                                        2012.10.31 20:50:49 CDT 
'suspend'
╭─ting@noa ~ ‹python-2.7.3› ‹ruby-1.9.3› 
╰─➤  gsettings get org.gnome.settings-daemon.plugins.power
lid-close-battery-action                                                    
2012.10.31 20:53:33 CDT 
'suspend'

The lid-close-{ac,battery}-action keys have been removed.
We really want lid close to be the way to suspend.
If you can't tolerate that, you can use systemd-inhibit to put an inhibitor in
place that will keep it from happening.

Hi Matthias,

I have modified systemd to get the behavior I want. As per bug 638865, there
are many reasons why *always* suspending when closing lid is poor design. I
don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's
case, they disable sleep when an external input device / monitor is plugged in.

If you choose to disregard users' complaints, now the problem is why do we have
these two ineffective settings in gnome-tweak-tool? Either they need to be
removed or fixed. Displaying broken switches leads to poor user experience.

I just ran into this too.  One of the first things I do when I install a laptop
is use gnome-tweak-tool to disable suspending on lid close.  I second the last
comment.  If you aren't going to fix it, then better remove those options from
gnome-tweak-tool...

(In reply to comment #4)
> Hi Matthias,
> 
> I have modified systemd to get the behavior I want. As per bug 638865, there
> are many reasons why *always* suspending when closing lid is poor design. I
> don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's
> case, they disable sleep when an external input device / monitor is plugged in.

We do that too, by default.
You can override this with the

org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor

setting.

> If you choose to disregard users' complaints, now the problem is why do we have
> these two ineffective settings in gnome-tweak-tool? Either they need to be
> removed or fixed. Displaying broken switches leads to poor user experience.

The settings are gone now.

(In reply to comment #6)
> (In reply to comment #4)

> > If you choose to disregard users' complaints, now the problem is why do we have
> > these two ineffective settings in gnome-tweak-tool? Either they need to be
> > removed or fixed. Displaying broken switches leads to poor user experience.
> 
> The settings are gone now.

To clarify - presumably the settings are gone in gnome-settings-daemon trunk?
They're still there in 3.6.1, and gnome-tweak-tool actually hasn't been
updated. I'll patch it tomorrow and send it upstream.

Is there a discussion somewhere of what trouble those options were causing? 
Would it possible to just have one checkbox to disable suspend on lid close,
like the one for having an external monitor?  That's all I care about.

They're removed in master, with this commit:

http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=58cb4eee64bbd8ca43111b1f80fdaacde8ad5f12

Can't remove them in 3.6, since the move to let systemd handle lid close has
only happened in master. We should perhaps put that patch into the f18 package
though, since that has the systemd patch and ignores the settings.

Ah, so this only affects Fedora 18, and somehow Arch Linux, but distributions
that use stock GNOME 3.6.x would not be affected?

In that case, the g-t-t fix should probably only go into master as well (I
don't think there's a 3.6 branch right now, but it should be created in this
case) and only cherry-picked for distros that carry the systemd patch.

Reported, with a patch, against gnome-tweak-tool:
https://bugzilla.gnome.org/show_bug.cgi?id=687413

I really can't understand why remove this option if it is already implemented
and it disturb nobody but it is pretty useful for a lot of people like me.

(In reply to comment #6)
> (In reply to comment #4)
> > Hi Matthias,
> > 
> > I have modified systemd to get the behavior I want. As per bug 638865, there
> > are many reasons why *always* suspending when closing lid is poor design. I
> > don't see why GNOME should follow suit and copy OS X behavior. Even in OS X's
> > case, they disable sleep when an external input device / monitor is plugged in.
> 
> We do that too, by default.
> You can override this with the
> 
> org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor
> 
> setting.
> 
> > If you choose to disregard users' complaints, now the problem is why do we have
> > these two ineffective settings in gnome-tweak-tool? Either they need to be
> > removed or fixed. Displaying broken switches leads to poor user experience.
> 
> The settings are gone now.


Closing the laptop lid when an external vga monitor is connected doesn't
suspend the system but the monitor shutdown himself.

In case I hadn't mentioned this here yet: the command to override the default
lid switch handling on a systemd system is:

systemd-inhibit --what=handle-lid-switch \
                --who=me \
                --why=because \
                --mode=block /bin/sh

(In reply to comment #13)
> Closing the laptop lid when an external vga monitor is connected doesn't
> suspend the system but the monitor shutdown himself.

This happens to me too on unreleased F18. The intended behaviour is to not
suspend on lid close if we are attached to an external monitor (+ input
devices) right?

@Mattias Bengtsson: Intended behavior is to suspend in all circumstances,
regardless of input devices or external monitors.

The behaviour depends on the 
org.gnome.settings-daemon.plugins.power lid-close-suspend-with-external-monitor
setting. gnome-tweak-tool has UI for this.

 $ dconf read
/org/gnome/settings-daemon/plugins/power/lid-close-suspend-with-external-monitor 
false

This is what's in dconf for me. Which I believe(?) also is the default.
However, the attached screen still shuts down on laptop lid close. It probably
doesn't suspend though, like Juan said above, so should this go in a separate
bug instead?.

Suffering from the same issue. Suspend doesn't care about a monitor connected
even if
/org/gnome/settings-daemon/plugins/power/lid-close-suspend-with-external-monitor
== false and just suspends.
Had to set HandleLidSwitch=ignore in /etc/systemd/logind.conf
Now the laptop only suspends if I tell it to by pressing the menu button...
wich I GUESS is not the desired way it should work... right?!

Am on Archlinux, Gnome 3.6.4, latest Kernel (3.6.9)

While suspending by default when the lid is closed is perfectly fine, removing
this option (option!) from Gnome Tweak Tool -- which is obviously an external
and advanced utility -- is definitely a bad idea. "Normal users" won't be
installing it anyway and advanced users will be trying to use it anyway to
change this behaviour. Not letting them do so will cause irritation without
contributing any good.

Additionally, this makes creating extensions that give you more control over
what the lid triggers (e. g.
https://extensions.gnome.org/extension/417/blank-on-lid/ ) very difficult and
platform-dependent (because now it's systemd, acpid or the like that handle
suspending).

Moreover, by not taking any action and not inhibiting daemons (instead of
forcing a suspend), Gnome Shell doesn't even ensure that the PC will suspend in
the first place! (If there is no systemd/acpid/..., the PC just won't react,
the screen won't even get locked!).

Any comments on these points?

If you read the other bug, the option was removed from the tweak tool because
support for that option was removed from Gnome.  And the screen will get locked
as normal after the idle timeout is reached.

(And don't shoot the messenger. :-)  I disagree with both of these decisions,
I'm just explaining the current situation.)

gnome-power-manager is not involved in this anymore

Okay, thank you. Do you know whom I should contact (or which bug to consult) to
try to convince them in order to have this functionality restored to Gnome?

This is the right place and they've been pretty clear that they won't
reconsider it.  See Bug 638865 for more details and discussion.

(In reply to comment #13)
> Closing the laptop lid when an external vga monitor is connected doesn't
> suspend the system but the monitor shutdown himself.

You'll have to wiggle your mouse I'm afraid, it should bring the display back
to life. It's fixed properly in master, and we have a test that specifically
checks to avoid this particular problem.

The test case.

commit 50badc695e22722d0f481c744f590fd8d8e39daa
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Jan 23 22:19:50 2013 +0100

    power: Additional check in test_no_suspend_lid_close

    Check that we do not blank the screen when closing the lid, and
    a 2nd monitor is plugged in.

    https://bugzilla.gnome.org/show_bug.cgi?id=687277

I registered just to comment on this bug/feature.

I use Gnome 3, love it, and frequently close my laptop's lid while jobs are
running, like running custom backups scripts at night. I understand making
suspend on lid close the default, but totally removing the ability to adjust
this behaviour strikes me as a harmful change with no obvious benefit.

I would really, really like to have the ability to blank the screen on lid
close returned.

(In reply to comment #27)
> I would really, really like to have the ability to blank the screen on lid
> close returned.

That won't be an option. You can block the lid-switch instead using
systemd-inhibit. Read the bug comments.

I did and I did. However, if the switch isn't used at all, the screen doesn't
blank when closed, as I understand it. So the backlight is left on and it runs
down the batteries. Hardly a good "fix".

Why is it so critical to remove this option from users? What hard could it have
been causing?

I also utterly disagree with this decision. It seems a bit like copying all the
bad habits or "negative features" from competing products...

Orest Tarasiuk:

Exactly. Gnome3 is nice and effective if you can configure it but it's more and
more difficult to. I'm spending my 2nd day searching for extensions and scripts
to configure Gnome3 in such a way that had been half an hour before... I will
never understand why it is good to disable options not used by everyone. It's
cool to hook suspend on the lid but what if it is some users want it an other
way? There were a couple of GOOD reasons listed above. The point is I want to
change it back and forth time by time and not mess with scripts.

Moreover:
I am working with an external monitor with the lid closed. (Which I usually
do.)
I switch to console by Alt+Ctrl+F2 for some reason.
Guess what? 
The computer goes to sleep.

(In reply to comment #31)
> Moreover:
> I am working with an external monitor with the lid closed. (Which I usually
> do.)
> I switch to console by Alt+Ctrl+F2 for some reason.
> Guess what? 
> The computer goes to sleep.

There's no guessing here. When you're at the console, systemd handles the lid,
not gnome-settings-daemon running in some user's session in an inactive VT, and
it sleeps by default when the lid is closed. Configure logind to not handle the
lid switch, and it won't suspend.

Excuse me for my bad English, I didn't catch one point from the discussion.
Which component is responsible for launching the suspend command on lid closing
(when a user works in the Gnome shell)?
Is it systemd or Gnome shell (i.e. gnome-settings-daemon or something like)?

OK, and do you think it's good design? 
I'm trying hard but still do not get why to take away that switch from the user
that made them possible to decide when they want their computer send to sleep
with the lid...

> There's no guessing here. When you're at the console, systemd handles the lid,
> not gnome-settings-daemon running in some user's session in an inactive VT, and
> it sleeps by default when the lid is closed. Configure logind to not handle the
> lid switch, and it won't suspend.

(In reply to comment #33)
> Excuse me for my bad English, I didn't catch one point from the discussion.
> Which component is responsible for launching the suspend command on lid closing
> (when a user works in the Gnome shell)?
> Is it systemd or Gnome shell (i.e. gnome-settings-daemon or something like)?

systemd will actually suspend the machine when you close the lid. Various
system components can prevent that by using block and delay inhibitors. Office
runner and gnome-settings-daemon are examples of each one of those.

(In reply to comment #34)
> OK, and do you think it's good design? 
> I'm trying hard but still do not get why to take away that switch from the user
> that made them possible to decide when they want their computer send to sleep
> with the lid...

Design doesn't come into it, the options weren't even user visible. From a code
architecture stand-point, we have less moving parts, less bugs, and less corner
cases. and something clean enough that we can have a test suite built on top of
it. And despite the repeated assertions to the contrary, we didn't take away
anything. the logind configuration and systemd-inhibit were mentioned a number
of times in this bug already.

And that discussion *still* doesn't have anything to do with the original bug
report.

(In reply to comment #35)
> And despite the repeated assertions to the contrary, we didn't take away anything.

What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key
inhibiting sleep mode on closing the lid. In 3.6, it doesn't.

(In reply to comment #36)
> (In reply to comment #35)
> > And despite the repeated assertions to the contrary, we didn't take away anything.
> 
> What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key
> inhibiting sleep mode on closing the lid. In 3.6, it doesn't.

It still does in 3.6 as well as in 3.4. Maybe not in the downstream
distribution you use, but that code upstream is the same as in 3.4. And there
lies the rub. That code didn't work with systemd, and the interaction was
completely broken for a number of cases. systemd works in a certain way, we
adapted our code to work with systemd.

In any case, there's no point carrying on this discussion, I've already
explained how to get your laptop not to suspend when closing the lid.

(In reply to comment #37)
> (In reply to comment #36)
> > (In reply to comment #35)
> > > And despite the repeated assertions to the contrary, we didn't take away anything.
> > 
> > What do you mean? In GS 3.4, gnome-settings-daemon respected the gconf key
> > inhibiting sleep mode on closing the lid. In 3.6, it doesn't.
> 
> It still does in 3.6 as well as in 3.4. Maybe not in the downstream
> distribution you use, but that code upstream is the same as in 3.4. And there
> lies the rub. That code didn't work with systemd, and the interaction was
> completely broken for a number of cases. systemd works in a certain way, we
> adapted our code to work with systemd.
> 
> In any case, there's no point carrying on this discussion, I've already
> explained how to get your laptop not to suspend when closing the lid.

Okay, this was unknown to me. I'm using Arch and the respective gconf key isn't
considered (this also seems to be the case for other distributions).

If the mentioned code is still in GS 3.6 upstream, what is the preferred method
of inhibiting sleep as viewed from the upstream perspective?

Thank you. As a programmer I've understood the clear design, but I believe the
point is that users (me too as a user) want to customize environment to meet
their normal everyday activity. And they want to do this from the shell. I mean
the Gnome shell, not CLI. And this is the root of the trouble.

(In reply to comment #40)
> Just install dconf-editor and call it a day. Go to: org > gnome >
> settings-daemon > plugins > power then set "lid-close-ac-action" and
> "lid-close-battery-action" to whatever you need. The default is suspend but if
> you set it to blank or nothing your computer will be able to continue playing
> music, downloading files, running backgrounds tasks, etc. with the lid display
> off but the rest of the unit running just fine.

Unfortunately, I'm pretty sure this hasn't worked since GNOME 3.6. Those keys
are now ignored, so it's impossible to configure GNOME with them (e.g. to
behave differently on lid close on AC vs battery power).

(In reply to comment #41)
> (In reply to comment #40)
> > Just install dconf-editor and call it a day. Go to: org > gnome >
> > settings-daemon > plugins > power then set "lid-close-ac-action" and
> > "lid-close-battery-action" to whatever you need. The default is suspend but if
> > you set it to blank or nothing your computer will be able to continue playing
> > music, downloading files, running backgrounds tasks, etc. with the lid display
> > off but the rest of the unit running just fine.
> 
> Unfortunately, I'm pretty sure this hasn't worked since GNOME 3.6. Those keys
> are now ignored, so it's impossible to configure GNOME with them (e.g. to
> behave differently on lid close on AC vs battery power).

I can confirm the methods I listed work. Running Gnome 3.6.3 in Fedora 18.

Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred
setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work
whether or not systemd is set to handle lid close events. If systemd handles
the lid switch, my system always suspends on lid close, and if not, it always
does nothing. Comment #3 would seem to indicate this is the intended behaviour,
although I guess I should probably do more testing to make sure there's nothing
in my setup getting in the way.

(In reply to comment #43)
> Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred
> setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work
> whether or not systemd is set to handle lid close events. If systemd handles
> the lid switch, my system always suspends on lid close, and if not, it always
> does nothing. Comment #3 would seem to indicate this is the intended behaviour,
> although I guess I should probably do more testing to make sure there's nothing
> in my setup getting in the way.

From a clean install of Fedora 18, (not sure what systemd handles it by default
or not, would assume it does) and updating only the kernel (using version
3.8.5) I just simply have to install dconf-editor (version 0.14.1-3.fc18), make
the aforementioned changes and I'm good. Both graphical and command line
methods I mentioned work just fine. To confirm the test, I opened a music video
on YouTube, began playing it before it could fully buffer even, closed the lid
and enjoyed the song in its entirety proving it didn't sleep because A.) It
could play the song and B.) My wi-fi adapter was able to finish loading the
entire stream. 

Not sure how much hardware plays a part in this but I'm using an ASUS R503U
with an AMD E8 1800 1.7GHz x2 64-bit APU with an ATI Radeon HD 7340 chipset.
I'm in legacy bios mode as I disabled the prison that is UEFI.

(In reply to comment #43)
> Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred
> setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work
> whether or not systemd is set to handle lid close events. If systemd handles
> the lid switch, my system always suspends on lid close, and if not, it always
> does nothing. Comment #3 would seem to indicate this is the intended behaviour,
> although I guess I should probably do more testing to make sure there's nothing
> in my setup getting in the way.

Just learned that the settings do not persist upon reboot however it remedies
itself if dconf-editor is opened again. The configurations are still the way I
left them so they don't reset upon reboot but apparently aren't read back into
the system until I launch it. Strange... programming is not my skill set;
repairs, design and bug testing are however, but with the problem isolated,
hopefully someone can fix it easily.

(In reply to comment #47)
> (In reply to comment #43)
> > Hmm. I'm also running 3.6.3 on Fedora 18, and I can't seem to get my preferred
> > setup (lid-close-ac-action = blank, lid-close-battery-action = suspend) to work
> > whether or not systemd is set to handle lid close events. If systemd handles
> > the lid switch, my system always suspends on lid close, and if not, it always
> > does nothing. Comment #3 would seem to indicate this is the intended behaviour,
> > although I guess I should probably do more testing to make sure there's nothing
> > in my setup getting in the way.
> 
> Just learned that the settings do not persist upon reboot however it remedies
> itself if dconf-editor is opened again. The configurations are still the way I
> left them so they don't reset upon reboot but apparently aren't read back into
> the system until I launch it. Strange... programming is not my skill set;
> repairs, design and bug testing are however, but with the problem isolated,
> hopefully someone can fix it easily.

EDIT: I actually don't need to open the setting again each time. Settings
remain set and condition remedies itself after the first suspend. I.E. Apply
settings, settings work for current session. Reboot, problem returns: system
suspends on lid close, subsequent lid closes that session obey dconf settings.

This is getting weirder by the minute. Not sure what the issue is anymore or if
this is gnome's or systemd's fault anymore but at least I've narrowed this down
a bit.

Just a friendly reminder to watch your language. I've hidden a few comments and
also banned a person.

Ah, after re-reading the earlier comments I see that the config keys in
question were only dropped after 3.6, but Fedora seems to carry cherry picked
patches which probably account for the partially working behaviour. Sorry for
the noise.

(In reply to comment #49)
> Just a friendly reminder to watch your language. I've hidden a few comments and
> also banned a person.

I'm sorry Olav. I'm going to keep myself in line from now on.

(In reply to comment #50)
> Ah, after re-reading the earlier comments I see that the config keys in
> question were only dropped after 3.6, but Fedora seems to carry cherry picked
> patches which probably account for the partially working behaviour. Sorry for
> the noise.

So that explains the weird behavior. Anyways, I wanted everyone to know that I
found a clean and pleasant work-around to this that's not nearly as messy as
playing around with inhibitor locks. Hopefully someone can make a GUI solution
in Gnome Tweak Tools or something that can do what I'm about to write here.

All one has to do is uncomment the HandleLidSwitch= line in
/etc/systemd/logind.conf and set the value to lock (This is case-sensitive.
Users can also use "ignore" without quotes if they don't want it to immediately
go to the lock screen) For good measure, you can also uncomment the
LidSwitchIgnoreInhibited= line and change the value from yes to off. (Or add
the lines if they do not exist)

Source: www.freedesktop.org/software/systemd/man/logind.conf.html

I tested this method and it worked on systemd based distros such as Fedora and
Arch. It think it's safe to assume that it will work on all systemd distros.
I'm going to open a feature request to see if someone can implement this clean
solution. All that's left to figure out how to achieve this on distros without
systemd.

(In reply to comment #51)
> All one has to do is uncomment the HandleLidSwitch= line in
> /etc/systemd/logind.conf and set the value to lock (This is case-sensitive.
> Users can also use "ignore" without quotes if they don't want it to immediately
> go to the lock screen) For good measure, you can also uncomment the
> LidSwitchIgnoreInhibited= line and change the value from yes to off. (Or add
> the lines if they do not exist)

Thank you for this. I was using the logind configuration to work around this
issue, but I was unaware I could make use of options beyond "ignore".

I'm not sure this is something GNOME Tweak Tool could handle though,
considering it's a system configuration file that needs root permissions to
edit. That's not to say there couldn't be a GUI tool for modifying systemd
configuration, but it would probably be outside the GNOME scope.

I'm curious as to how this is handled on non-systemd distros. Do
upstart/initd/etc. have their own event handling, or does it all go straight to
the DE?

Ok, I did understand how to disable suspending when the lid closes (editing
/etc/systemd/logind.conf)
Now is there a way to *disable* the suspend for AC power and *enable* the
suspend for battery?
Quite frankly, I have little desire to edit system configuration files every
time I plugin in or out my power cord.

Also, will there be graphical settings for this?

(In reply to comment #3)
> The lid-close-{ac,battery}-action keys have been removed.
> We really want lid close to be the way to suspend.

I mean, that's just like your opinion man... But I really don't get the desire
of the GNOME project to force behaviour on people instead of presenting a
choice. If I wanted an operating system that decides over my head what I want
and need, I would use Mac OS.