This bug is also on Ubuntu Mate 14.10 & 15.04 beta

I must close steam before shutting down , or it is very slow , same behavior. If I just try to shutdown , steam hangs the shutdown by 30 seconds.

System Information:
http://pastebin.com/WZWfndnS

Exists in Cinnamon too, on both Arch and Mint.

Issue is ongoing

I'm experiencing this issue as well on my new Ubuntu MATE 16.04 install. If the development team needs some log files or someone to test something, @ mention me and I'll be happy to help.

STILL ONGOING, Mint 18 mate

The exact same thing happens to me in Fedora 24 with Mate or Cinnamon, as well as Ubuntu Mate 16.04.1.

Did the most recent client update fix this for all of you? They said they fixed something about shutting down with Steam open.

It didn't. It still delays the shutdown of MATE and Cinnamon by whatever amount SystemD is set to delay it for.

Yeah, which is strange. There must be some additional process that still doesn't listen to SIGTERM, although Steam definitely appears to shut down on it. Maybe Steam takes too long to quit?

this issue was NOT resolved, mint 18.1 mate, still hangs for 30 seconds on shutdown if steam is open

Maybe Steam takes too long to quit?

This wouldn't surprise me at all. I've had issues in the past with Steam holding up the shutdown process in Windows.

Same here, Issue still exists with Linux Mint 18.1 64-bit Cinnamon.

Same here, Issue still exists with Linux Mint 18.1 64-bit Mate.

Same issue. Linux Mint 18.2 Cinnamon 64-bit.

Steam should obey SIGTERM now, any details on what exactly is happening? Is the Mint session relying on some other mechanism to instruct the client to exit?

My best guess is that Steam, on SIGTERM, takes too long to shut down, causing the system to wait (and eventually time out) on shutdown request. I don't 100% understand why the system doesn't catch Steam's process shutting down, unless there is another Steam process that keeps running in the background...

Even with downloads running, the client always exits gracefully under a few seconds here if I manually send it SIGTERM.

Something I am noticing now is that when I go to shut down while Steam is running, it forces Steam to quit, but then doesn't actually shut down; it just stays on a fully-functional desktop with everything except Steam still running. I have to pull up the shutdown option a second time. When I manually exit Steam first, and then hit the shutdown button, it shuts down properly the first time. This is on Kubuntu 17.04.

I have seen this very behaviour on KDE as well. On MATE it still does the same old thing, where shutdown becomes delayed by 90 seconds (which is the SystemD default timeout).

Even with downloads running, the client always exits gracefully under a few seconds here if I manually send it SIGTERM.

I'm guessing that's the issue. A few seconds is longer than the rest of the system takes to shutdown, at least on my end.

Same behaviour here with Arch + XFCE. I think it only started recently, but can't pin it down to an exact date.

Same behaviour with xubuntu and manjaro. It started to gobble the shutdown signal about 2 weeks ago.

@frikisama Same scenario. Second week of July I came back to my PC a minute later to find it hadn't rebooted. Thought I just "didn't reboot". July 14th I realised it was a bug. For me I believe it started some time between July 5th and July 10th. I could be wrong of course. :-|

Going through pacman log I found very few xfce-related packages that had been updated recently. Even so, downgrading those packages did not help in any way.

Same issue with Manjaro and KDE. Plasma 5.10.3.

Same here with Linux Mint 18 (Cinnamon). It cancels the shutdown completely, but still exits Steam. I managed to screen shot the steam client shutting down window for a second after Cinnamon tried to shut down. I'm not sure when this started but it was a couple months ago it seems like, which is odd since this bug is from 2014.

Switched to Ubuntu Mate 17.04.4
Same Problem, need to shutdown "twice".
(First one only exit steam.)

To add, happening on Fedora 25 as well, also with XFCE. I think it is safe to say this is not a distro-specific problem.

I had also this problem with Steam and some other applications so I created a work around solution using Plasma Event Notification and Actions.

Run "Notifications"
Go to Event Source--> Plasma Workspace ===> Logout Canceled

In Plasma Notifications you can create a command to run when a "Logout Canceled" event had happened.
So I just created a shut.sh script and made it executable that includes
#! /bin/bash
shutdown -P now

So every time a "Logout Canceled" event happens it just runs that script and it shuts down the pc...

@wolfyrion
So every event which cancel the logout will shutdown the computer?
That's sound like you want to kill an insect with a gatling gun.

@wolfyrion: I applaud your ingenuity - but @MartinX3 is right. The workaround also probably won't work unless you're using KDE.

The most likely bad scenario of course is where I click logout and an app shows that I hadn't saved something, prompting me to do the save. Except, too late, forced shutdown in progress. :-|

@MartinX3 @zatricky : yeap you are right, only people with plasma can implement this work around.
As for the bash script, I just posted what works for me but you can modify it according to your needs like for example to shutdown your PC after a min or secs, is a bash script so you can actually do whatever you want after a "Logout Canceled" event .
Well I am not using any other DE than KDE but even if I was using another DE I think I would create a shutdown button bash script , just to exit steam and shutdown the PC so as to make it easier for me until Steam fixes this problem.

(I use my pc for rendering or farming steam cards so I have to automatically shutdown my PC because I am not always at home. Temperatures are a bit high these days so I was using Kshutdown to schedule when the pc will be shutdown but unfortunately because of steam and some other apps my pc was not shutting down thats why I used that solution.)

[ EDIT ] It seems if Kodi shuts down, Steam doesn't gobble the request. But XFCE still can't shut down on the first attempt. :-/
Original:
This issue appears to no longer affect XFCE+Arch for me - but does still appear to affect my XFCE + Fedora 25 install.

Having this issue on Arch with KDE. I should add that it's been happening since I installed Arch 3-5 weeks ago

Having the same issue - Arch with KDE

Been ongoing for me since install about a year ago

Same issue on Xubuntu 17.04, I have to press shutdown/restart twice in order to get it to work (first time seems to just kill Steam), seemed to start around the time I upgraded from 16.10 to 17.04. Also, not sure if this is related, but around the same time my system started freezing on resume from suspend with Steam open.

is someone working on this? @triage-valve got assigned to this issue over 3 years ago and didn't even leave a comment yet.

@property-live Yea, it is kind of ridiculous. However, considering us Linux uses make up less than one percent of the steam users (http://store.steampowered.com/hwsurvey) it only makes sense from a business perspective (though it kind of shows that even they do not have faith in their own Linux-based Steam Machines/SteamOS considering such a little bug has gone under the radar for so many years...).

Commenting to confirm as well, still seeing this behavior on Linux Mint 18.2 Cinnamon. Pressing shutdown once closes Steam, but the system never subsequently shuts down unless I repeat the shutdown request with Steam not running. Closing Steam manually and then shutting down does not present any delays.

I can confirm that this issue occurs on a relatively clean installation of Debian 9.1 (using XFCE) and I've experienced it before on Debian 8 using Cinnamon as well.

Confirmed on Kubuntu 16.04.3, I have to select shutdown twice if I have Steam client running. Latest Steam Beta is installed. This problem has started occuring since the last few weeks.

I also confirm it on Ubuntu 17.04, OpenSUSE 42.3 and tumbleweed. No problem on Manjaro though.

Not sure if it means anything, but ending the session with something like Ctrl-Alt-Backspace or shutting down through a terminal doesn't cause this problem.

Confirmed on Manjaro and KDE, Plasma 5.10.5. I extended @wolfyrion's approach and added both a notification and a 60s delay, allowing me to save any unsaved docs:

`#!/bin/bash

notify-send --app-name="Shutdown" "Shutdown failed; forced shutdown in 60 seconds"
sleep 60
shutdown -P now`

I've begun attempting to reproduce this issue on virtual machines to see what actually causes it to occur.
Currently I've tried a fresh Debian 9.1 installation (Debian desktop environment) with Steam installed from the repo. The issue does not occur - in fact Steam automatically shuts down shortly after this dialog appears.

I'm going to install some addition DE's and see if that has any effect.

From what I've been able to find online where other projects have fixed similar issues, depending on what library Steam uses to interface with the DM, it may incorrectly return the close event with an "ignore", which causes the DM to cancel the logout. Alternatively, it might incorrectly return a "veto" to the close event, which is how applications normally prevent data loss with possibly-important unsaved content.

@zatricky Yeah, that seems to be the case - I just installed xfce4 on the same system and logout / shutdown are canceled by Steam.

It might also be worth noting that I had to enable lightdm as the default display manager because when I used gdm3, I was unable to start an xfce4 session.

Edit:
I've confirmed that lightdm w/ Debian's default DE does not reproduce the issue.

• Running sudo apt-get install xfce4 (and enabling lightdm as the default display manager when it asks) on a fresh installation of Debian 9.1 (with Debian Desktop Environment chosen as the desktop environment when installing the OS) does appear to reproduce the issue reliably. On my actual installation of Debian, I have XFCE installed as the only DE and the issue is present - so chances are XFCE (and other affected DE's) always have the issue regardless of what other DE's are installed.

On Debian 9.1 with XFCE 4.12 it seems that the Steam logout dialog is interpreted as an error dialog and even though it cycles in and out on it's own (ie. completes logout/shutdown of Steam) it seems to return a value that xfce4-session sees as cancellation request. Which side of the fence the problem lays would require more digging, but maybe this helps someone to do it:

TRACE[xfsm-manager.c:1295] xfsm_manager_save_yourself_done(): enteringTRACE[sm-layer.c:232] sm_interact_request(): Client Id = 26d3bf123-032c-4cd7-97cd-aaa2114d9662, received INTERACT REQUEST [Dialog type = Error]
TRACE[sm-layer.c:246] sm_interact_done(): Client Id = 26d3bf123-032c-4cd7-97cd-aaa2114d9662, received INTERACT DONE [Cancel shutdown = True]
TRACE[xfsm-manager.c:303] xfsm_manager_set_state(): state is now XFSM_MANAGER_CHECKPOINT
TRACE[sm-layer.c:304] sm_save_yourself_done(): Client Id = 26d3bf123-032c-4cd7-97cd-aaa2114d9662, received SAVE YOURSELF DONE [Success = False]

Same issue on the newest MacOS. It's been 3 years already since ticket creation: are the Steam-guys even looking at it?

It doesn't look like it, it shouldn't even be too hard to fix. Maybe we can try contacting them directly if they pay no attention to the GitHub?

This isn't really a three year old problem though, it started for me just a month or so ago. I wish I could say if it were after a system update or Steam update, and which/when exactly but I don't really know. Then only time I reboot my computer is when an update requires it. Otherwise it's in hibernation when I'm not on it.

I think it was after an KDE update for me. Don't know which one it was through. They must have changed some handling when an application opens another window after receiving shutdown notification.

I don't think KDE is the problem now. I haven't updated my laptop in a while, it's using Plasma 5.9.4, KDE Framework 5.31.0 and QT 5.7.1 and rebooted with no problems. Steam updated itself right after that, and now it's got this issue and won't reboot on the first try. I wish I'd checked the Steam version before rebooting, but I only use my laptop for streaming games and only update Steam when it forces me to. It updated to the one built July 17, API v017 and package version 1500335472. A subsequent reboot updated Steam to an Aug 28 build and package version 1503954609, same API and same issue.

I'm pretty certain this is a Steam Issue now, most likely introduced in the July 17 build.

The whole Steam process tree now closes promptly and gracefully when it gets a SIGTERM event. Steam has no awareness of higher-level inter-client communication around session shutdown, etc. If there's some such convention we're violating, we're not aware of it. Fixing the issue with SIGTERM allowed several major desktop environments to start logging out properly, so the remaining issues most likely are less general, and potentially related to behaviors specific to the desktop environments. If a developer for the affected desktop environments is able to give us information as to what behavior to change in order to avoid this issue, please attach it to this report or contact us directly, but just confirming the report or theorizing is not helpful.

Please don't bring up macOS as that is completely different and off-topic.

@Plagman Are you referring to a previous update, the current version, or an upcoming version?

Previous update; nothing has changed recently on that front.

I am running a fully updated Linux Mint Cinnamon 18.2 on a 4.11 Linux Kernel with AMD HD 7770 GPU and no closed source drivers.

When Steam is on the system tray and I ask the system to shutdown, Steam closes but shutdown sequence is aborted.

Its not just a long delay before shutdown carries on, Steam closes but somehow aborts the sequence. Then if I ask again for the system to shutdown it works immediately, as it does when Steam is manually "exited" before asking the system for a shutdown.

Despite old reports on Github the issue is quite recent for me (certainly 2017, probably since July).

Others have reported similar issues here: http://steamcommunity.com/app/221410/discussions/0/1474222595306056410/

It seems this is where the message happens:
https://github.com/KDE/plasma-workspace/commit/616f57aecf6193efc333174360190549e2e4dcdb

As to what triggers it: vlc had similar issues in the past:
https://mailman.videolan.org/pipermail/vlc-commits/2011-July/007707.html

I am pretty sure the answer is hidden here:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
"Termination" is marked obsolete, but according to the vlc patch (from 2011) this was related to their issue.

EDIT:
I traced the behaviour as far as this:
https://github.com/KDE/plasma-workspace/blob/master/ksmserver/server.cpp

Please note that they indeed handle the "obsolete" marked termination behaviour with the WM_SAVE_YOURSELF message. So my guess is that you need to "send a PropertyNotify event on WM_COMMAND" as answer. Compare:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#saving_client_state

Just started recognizing this bug a few days ago for the first time.
I'm using Manjaro with the Nvidia-Drivers (v375.82).
It could have something to do with changing my Kernel from 4.8 to 4.12? Not completly sure on that but worth a try.

Just like kisak-valve said above:

I might as well add a note to that, with KDE on Arch, I see a notification from Plasma Workspace that says Logout canceled by '' when the steam window visibly closes, but steam itself finishes closing a second or two later which is seen by the steam tray icon leaving the tray.

I have been having this issue for a month or so now. I don't know where steam logs are, so please direct me to them if the following info is not enough.
Started steam from command line, waited for it to initialise. the following messages come after giving the shut down
Ubuntu 16.04.3 with Cinnamon (no packages to be updated in software updater)

Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
process 5993: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2794.
This is normally a bug in some application using the D-Bus library.
process 5993: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2794.
This is normally a bug in some application using the D-Bus library.
process 5993: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2794.
This is normally a bug in some application using the D-Bus library.
[2017-09-20 16:22:18] Startup - updater built Sep  6 2017 20:37:15
[2017-09-20 16:22:18] Verifying installation...
[2017-09-20 16:22:18] Verification complete
[2017-09-20 16:26:09] Shutdown

Same symptoms as others. On shutdown, steam exits, but shutdown is cancelled

having this issue on manjaro, kde edition.
Its a real pain. Any progress on a fix for it?

same. manjaro, kde edition.

And same here. Shutdown attempt with Steam running - Steam exits, shutdown cancelled (no notification on this version of Plasma). Shutdown without Steam running proceeds as normal.

Is there any additional info we could provide in order to hopefully get this issue resolved?

Edit: My apologies, I hadn't noticed Plagman's comment.

Arch Linux with Xfce here, same problem.

I have installed kubuntu-desktop after an upgrade to (beta) Ubuntu 17.10 . The error never occurred in Unity but now in KDE I have to do "logout" twice because apparently steam cancels it the first time

I really wish it were easy to give more compact "me too"s in github issues. :-/

I've noticed the following behaviour and suspect strongly that it is the same issue. If it is the same issue, these steps will be FAR easier to troubleshoot the cause:

• Ensure Steam is not running (can quit Steam or just do the next step before logging in to the computer)
• Disconnect network
• Launch steam
• Wait for Steam login to time out in order that it presents the option to "RETRY CONNECTION", "START IN OFFLINE MODE", or "QUIT".
• Though unnecessary for the test, you can now reconnect the network
• Attempt to log out or shutdown/reboot. Steam prevents this.
• tap "Quit" to quit Steam
• Attempt to log out or shutdown/reboot. Succeeds.

October 17 2017 update has the same issue.
Steps to reproduce has been written here quite a lot of times, but I'll write again with minimal steps

1. Open Steam app (/usr/bin/steam -silent) with no special env vars
2. Select shutdown/restart

Observed result :
Steam app closes but shutdown/restart does not occur

Expected result :
Steam app closes and shutdown/restart occurs

If the devs are not getting the observed result, can anyone post any env vars they are using which enables expected result?

@renjithis As I said before - the issue can be reproduced on a fresh installation of Debian 9 w/ Cinnamon and XFCE - So they wouldn't have to worry about env vars or any additionally installed programs. I don't know why they've yet to address the issue when it can be reproduced on a clean system 100% of the time in a VM...

Are we that much of a minority in an already minor portion of steam for linux users that they are ignoring us?
The last update didn't even have a Linux/SteamOS section, it only had genral, windows and mac. I thought we amounted more than Mac users who use Steam

So I'm not an expert, I'm willing to help identify. If anyone wants to point me to what log files are needed, etc I'm more than happy to collect information and post. I'm keeping my Linux Mint install very up to date along with the Steam client and the issue is still there. It's the only program out of everything I've tried that does it though.

Maybe we should bring this to the attention of the affected DE's developers by opening issues on the corresponding bug trackers. Don't think they gonna magically notice this here.

I thought this was the place where issues with Steam for Linux is supposed to be reported (It still implies in the repo's description). Do we have a new place where we can report them?

I was under the impression that confirmed issues will be posted by the repo admin/mods to the developer's bug tracker (which I would expect to be private).

@kisak-valve What more info can we provide that will help you (or who is working on this issue) identify the cause of the issue?

@renjithis I'm talking about the DE's developers, not steam. If you read the post way above by @Plagman he states that this will most likely not be fixed without the DE's help of tracking down what steam does wrong/ doesn't do.

If anyone makes a bug report at any DE's bugtracker, link it here so we can add ourselves to the CC lists/vote for the bug.

elementary OS/Pantheon: https://bugs.launchpad.net/elementaryos
MATE (not sure which repo would be appropriate): https://github.com/mate-desktop
Cinnamon: https://github.com/linuxmint/Cinnamon/issues
KDE: https://bugs.kde.org/
Xfce: https://bugzilla.xfce.org/
GNOME: https://bugzilla.gnome.org/

https://bugzilla.xfce.org/show_bug.cgi?id=13841

Not sure if more information is needed there

Here's a thread recently started by someone else over in Mint land:

https://bugs.launchpad.net/linuxmint/+bug/1713601

Is anyone on the x.org mailing list? Other than the Kernel that's the only thing I can fathom is the same through multiple distro's and DE's.

Has anyone opened issue with Cinnamon? Should I do it?

Edit :
This seems to be their bug tracking https://github.com/linuxmint/Cinnamon/issues

the latest release note say "Fixed an issue that could result in Steam blocking system shutdown or user logout."
has anyone tried it yet?

I think, it helped on Ubuntu Mate x64 17.10.

Edit:
I'm not sure.
Sometimes the fix doesn't work.

Edit0:
Standby works now. But Shutdown doesn't...

How can this issue persist for more than 3 years? Valve... Pls fix

Unfortunately we are just in the super minority, so we are pretty low priority. I've been fastidious about keeping steam and mint completely up to date and it still cancels the shutdown. Hopefully someday someone will fix for us.

Still an issue with xfce 4.12 on Ubuntu 17.10

ongoing in mint 18.2 and 18.3 beta

Retested after fresh install of Linux Mint 18.3 Cinnamon Edition (not beta)
and it is still happening here too.
Booting most recent versions of kernels 4.4, 4.8, 4.10, 4.11 and 4.13
available through the linux mint update manager made no diference. Those
are the Ubuntu Kernels pulled from kernel.ubuntu.org made available by
Canonical for Ubuntu 16.04 AFAIK.

It is important to note that right after asking for a power off (or reboot,
that also suffers from the same issue) I can very briefly see a dialog
window pop up on the center of the screen, saying it is syncing stuff and
asking me to confirm whether or not I want Steam to be force-closed
(something like that... too fast for me to read it properly or to take a
screenshot).

Then it closes, and the tray icon disappears, but the shutdown sequence is
halted.

Also, it seems that no othe software is ever closed before the sequence is
interrupted, so this all happens before linux tries to kill off anyone
remaining after asking nicely.

[Warning: all that follows bellow is observations and conjectures from an
attentive user but not a software programmer]

Finally I should add that I've seen something similar to this behavior on
Windows, where having notepad open to an unsaved but edited text file
prevents shutdown because the sequence is halted and aborted when a
save/close file dialog is offered by notepad to the user.

Maybe the fact that Steam is producing a new dialog window to interact with
the user is the trigger for the unwanted behavior. It does need to sync
saves to the cloud and stuff, but maybe it could wait for a while without
producing the dialog and only if this time limit is surpassed before
finishing sync it shows the dialog. This way a fast enough sync won't
produce a dialog window at all and maybe this prevents the issue...

As far as I know Ubuntu gnome 17.04 and Ubuntu mate aren't affected by this. They have a 30 second shutdown period where you can choose to shut to the computer down now or let it wait for 30 seconds.

I might as well add a note to that, with KDE on Arch, I see a notification from Plasma Workspace that says Logout canceled by '' when the steam window visibly closes, but steam itself finishes closing a second or two later which is seen by the steam tray icon leaving the tray.

Yes! This is exactly what's happening on my system (kde neon) and it's driving me nuts! Please @kisak-valve, is there any way I can help provide more info? I'm seriously considering preventing steam from auto-starting, it is getting so infuriating.

EDIT: There is a KDE bug here: https://bugs.kde.org/show_bug.cgi?id=387587

Still happening with xfce as well.

I am experiencing the same issuen as reported earlier in this threaed:

[...]when I go to shut down while Steam is running, it forces Steam to quit, but then doesn't actually shut down; it just stays on a fully-functional desktop with everything except Steam still running. I have to pull up the shutdown option a second time. When I manually exit Steam first, and then hit the shutdown button, it shuts down properly the first time.

Arch XFCE.

Very annoying behavior. Same result on Fedora 27 KDE.

Yes, despite the obvious signs that the bug is on Steam-for-Linux since it
affects multiple Distros and DEs, including Ubuntu (the only officially
supported distro), bug reports about this issue were opened for various
Distros and DEs.

If you read through the first few messages on this issue (and some other
similar issues on Valve's steam-for-linux Github), you will see that Valve
devs have on occasion manifested themselves. For the most part, they asked
those issues to be opened against each Distro/DE to get help from their
respective devs in identifying the cause for the issue.

Unfortunately I am not a Valve dev (I am not even a software dev at all) so
I don't know more the current status in their attempts to fix the issue.

In any case, if anyone keeping tabs on the issue against a Distro/DE gets
an answer from devs there, it would probably be good to alert here about
that.

2018-01-01 17:44 GMT-02:00 Koopa [email protected]:

EDIT: There is a KDE bug here: https://bugs.kde.org/show_bug.cgi?id=387587

But isn't this a bug in Steam? I've experienced this in XFCE, in addition
to KDE.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-354672319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmGrzKg0-nCjb5Yi2bghDVvOaMzVmks5tGTWqgaJpZM4B6Vr_
.

Occurs on Ubuntu MATE 16.04 LTS (64-bit).

Is one of us going to have to land a job at Valve to fix this? I'm going for a CS masters this fall, I think they recruit from Digipen, I could see about fixing the problem in two years.

Also still occurs on Ubuntu 18.04 (bionic beaver) development branch when using latest KDE plasma desktop packages from Ubuntu's devel repos.

For the most part, they asked those issues to be opened against each Distro/DE to get help from their respective devs in identifying the cause for the issue.

That seems like it's pushing the problem on the DE devs, when Steam is the only app exhibiting this problem. The Steam devs should be the ones talking to the DE devs if anything, as we can't ask the right questions or provide the right info without access to the client source.

@Zerophase lol

Is one of us going to have to land a job at Valve to fix this? I'm going for a CS masters this fall, I think they recruit from Digipen, I could see about fixing the problem in two years.

The funny thing is, had they open-sourced the client, they'd have 3 pull requests with this nonsense fixed like a year ago.

That seems like it's pushing the problem on the DE devs, when Steam is the only app exhibiting this problem.

All of a sudden introduce a previously nonexistent new bug to your closed-source software and start blaming all the other open-source projects for this bug. Now that is something worth discussing about in Software Engineering courses in CS programs.

@outfrost I understand why they don't want to open source this would let competitors catch up, but then again might drop development costs. At least open source a small module for starting up and shutting down Steam.

what competitors?

@kisak-valve: Could you (or somebody else) be more specific on which DEs allow proper shutdown? Reading through the comments, I have the impression that each single DE in existence (besides of maybe GNOME) is hit by this bug.

@gvlfm78 cd projekt red.

I suspect @paulovilli is right about the culprit being that "Shutting down Steam..." window. KDE probably has some code that checks if any new windows are spawned in the split second after getting a shutdown command, in case a program wants to say "This file has not been saved. Save now?" And that's kind of what that window is for. If the sync and logout take more than a few seconds, it changes to a dialog asking if the user wants to keep trying or quit anyway.

So we're kind of at an impasse. You don't want Steam to just get rid of that window, because it might lose or even corrupt save data if syncing takes too long. And you don't want KDE to ignore it for the same reason. It could be tweaked so it pauses the shutdown until any newly-spawned windows have been closed, and then resumes, but that would mess things up if users click "Don't Quit" on one of those unsaved-files dialogs.

The problem is, there's no standard for apps to signal directly that they want to delay a shutdown, and then later say to either resume or cancel it. And even if someone were to create one, any older apps that aren't compliant will be stuck losing unsaved data.

@kisak-valve can't you reproduce the bug? I mean it clearly happens often enough, should be easy to reproduce and since you have the code, then follow it up to see what's going on.

In my case: install a fresh Debian + KDE, install Steam, open Steam, shutdown computer -> won't shut down. Only ever happens with Steam open.

@stevethepocket there is actually a standard for delaying a shutdown and even a sleep. It is available in systemd 183 (available since 25 May 2012) and later and is called inhibit.
https://www.freedesktop.org/wiki/Software/systemd/inhibit/

Completely agreed @MarcosCC.

@kisak-valve A lot of us Linux users are likely casual Linux users, and don't know all the various fancy internals of how the shutdown gets prevented. And considering how only Steam is the culprit here, this is likely an issue with how Steam handles shutdown. We don't have the ability to debug your Steam client, so we'd have no idea as to what Steam is doing wrong regarding its shutdown process.

We only have the very simple and consistent repro steps, surely just being able to consistently reproduce this problem on your machine with our steps would be enough to help debug and fix the issue.

I just want to put in a quick note, it's not just KDE that has this problem, at least Cinnamon, a fork of GNOME also has this problem, on both of my "daily driver" installs.

Everyone else who hasn't commented yet, I know it sucks to have to register an account to say "me too", but please do (it only takes a minute). We need as much feedback here as we can get. We are in a minority of Valve's problems here, so the bigger the voice, the better.

• [x] Cinnamon
• [x] KDE
• [x] XFCE
• [x] MATE
• [ ] GNOME

that's 4 out of 5 listed DEs doing it now

@SEAPUNK you forgot Unity

Just to corroborate @SEAPUNK, I've tested all major DEs in a vanilla Ubuntu 17.10 virtual machine to see if the bug reproduces. To be clear, this is the procedure:

-Install Steam
-Log into Steam account
-Try to reboot computer from application menu
-Reboot is cancelled. Steam window pops up for a brief moment.
-Try to reboot a second time, reboot completes.

GNOME: Inconsistent. It seemed to stop the shutdown the first time but after repeated tries, Steam shutdown normally and the VM rebooted.
Xfce: Yes.
MATE: Yes.
KDE: Yes, with "Logout cancelled by ''" error.
Cinnamon (tested in Mint 18.3): Yes.
Unity: Unable to test (it hates me) but assuming similar behavior to GNOME.

Is it possible to have Steam run in a mode where it launches a game and then exits after the game has finished? It already gives desktop launchers to run specific titles, and it seems to know how long I've been playing, so it must feel like it can tell when the game has been exited. This wouldn't be ideal for switching games because of the overhead, but it would be a good enough workaround for me. I would just have to remember that if I went to the steam store or wanted to chat that I'd need to close Steam manually afterwards.

At this point, it sounds like it might be more realistic to have a distribution/DE workaround that consists in sending a SIGTERM to steam (if running) prior to closing the DE session...

Well what if Steam Cloud sync ran as a service? It wouldn't have to cancel nor inhibit desktop session shutdown in order to complete the sync, and init systems (such as systemd) have good support for processes that need a few extra seconds before terminating.

It seems my Debian sid 64-bit can shutdown properly after switched from xfce4 to LxQt 0.12

I can confirm experiencing this issue on Manjaro with KDE Plasman 5.11.5.

Confirmed bug on Fedora 27 with cinnamon spin.

I believe that, at this point, Valve have more than enough information about distros and DEs to reproduce the issue.

Came across this systemd service to peacefully shut down Deluge. Could this be adapted for Steam to alleviate the problem?

https://gist.github.com/DrDoctor13/42168677f5c2a39594f5ab438c25cdb2

@ Buck Shockley

That script "peacefully" (read automatically and silently) kills deluge,
so it will not solve the issue exactly.

At best it is a workaround, but it might cause cloud savefile corruption,
desync or something like it because whatever Steam is doing when killed it
will stop in the middle of doing it.

We want Steam to be able to finish syncing savegames and whatnot to the
cloud before it closes.

We just don't want it to cause the system to give up on shutting down while
waiting for steam to finish that.

My suspicion is that when Steam opens a new dialog window while shutdown is
being processed it causes the system to stop the sequence.

So the best potential solutions yet were probably suggested by Sefa Eyeoglu
and Outfrost, when they remembered that systemd can receive some form of
"delay shutdown" signal from Steam.

On Jan 10, 2018 17:35, "Buck Shockley" [email protected] wrote:

Came across this systemd service to peacefully shut down Deluge. Could this
be adapted for Steam to alleviate the problem?

https://gist.github.com/DrDoctor13/42168677f5c2a39594f5ab438c25cdb2

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-356712203,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmOD4-DZ7HYBkF7GAtsbpZYTKOsf-ks5tJRDngaJpZM4B6Vr_
.

Void, xfce4 checking in.

@paulovilli What if SIGTERM is sent to Steam instead of SIGKILL? Running pkill -15 steam seems fine.

(re)disclaimer: I am not a software programer, just a nosey end-user

that being said, isn't that the same signal sent by the system to all
processes when you ask it to shutdown?

I believe it would then have the same outcome if the signal is sent by a
dedicated systemd service (like the one you mentioned) or by the
shutting-down system (afaik handled by systemd too?)...

but maybe not, this is waaaay over my level of knowledge!

On Jan 16, 2018 13:13, "Buck Shockley" [email protected] wrote:

@paulovilli https://github.com/paulovilli What if SIGTERM is sent to
Steam instead of SIGKILL? Running pkill -15 steam seems fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-357991000,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmN2zz_tQUxNo4cMXhrwXKYdqP6QGks5tLLymgaJpZM4B6Vr_
.

@paulovilli Not quite. SIGKILL will kill the process immediately and not give it a chance to clean up. SIGTERM also kills the process, but gives it a chance to clean up, i.e. finish syncing or pause downloads.

yes, I am aware of that difference and I saw that you now suggested SIGTERM
(by means of the "-15" parameter sent to pkill).
this time my question is what good will it do to use this systemd service
to send SIGTERM instead of the usual shutdown sequence doing it...

because either way (SIGTERM by systemd service or SIGTERM by shutdown
sequence) Steam is going to take its sweet long time to syng and exit, and
will pop up a dialog window in the middle of doing it

do you think this will be enough for the shutdown sequence to not stop
(presumably because of the popup dialog window)?
...or that we can add anything more to this service (like systemd "inhibit"
as proposed by Sefa) so it will kindly ask shutdown sequence to have
patience instead of giving up?

2018-01-16 14:05 GMT-02:00 Buck Shockley [email protected]:

@paulovilli https://github.com/paulovilli Not quite. SIGKILL will kill
the process immediately and not give it a chance to clean up. SIGTERM also
kills the process, but gives it a chance to clean up, i.e. finish syncing
or pause downloads.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-358011936,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmBYetnovhOlgACi0ONhfgwOtUeFHks5tLMizgaJpZM4B6Vr_
.

My proposal is to have a separate, background service just for Steam Cloud Sync (and any other tasks that need to be stopped gracefully) that would run completely separate from any user logins and DE sessions. The desktop Steam client could simply connect to that service to carry out its sync duties (exchanging authentication info in the process) and use it for that purpose whenever needed. In fact, many clients could connect to that same service, each from a different system and/or Steam user, and be distinguished between by the service. This would not only ensure that the desktop client doesn't need to spawn a window and cancel shutdown (and that it can thus be killed safely), but it would also have the added benefit of Steam Cloud Sync and anything else included in the service being shielded from desktop client crashes, sudden display server restarts, etc. On shutdown, the DE could then simply exit immediately, while the init system would wait for the Steam service to get its stuff wrapped up.

I just threw together a small program that logs the signals it receives just before it exits; It received SIGHUP when I tried to log off (in Cinnamon). Is the issue perhaps that non-Gnome environments are sending different signals (e.g. SIGTERM)?

Is it a bash script? can you share the code here somehow so we can test
which signal each distro/DE is sending?

Just to confirm... SIGHUP is the signal sent to Steam by Cinnamon (Linux
Mint? which version? which kernel version?) as soon as you ask the system
to shutdown?

From this explanation (
http://meinit.nl/the-3-most-important-kill-signals-on-the-linux-unix-command-line)
I would guess usual shutdown behavior would be sending SIGHUP at first then
some more aggressive signals after some elapsed time.

The weird thing is, despite the description from
https://en.wikipedia.org/wiki/Signal_(IPC), Steam didn't react to Ctrl+D
when ran from terminal (Ctrl+D sent with terminal window in focus), not
even returning any message in the terminal.

When I tried Ctrl+C to send it SIGINT it also did not close, just returned
this message and kept going: "^CForced create but already created for
SharedObjectEvent". That means it is programed to handle SIGINT internally
somehow, right?

When I tried Ctrl+\ to send it SIGQUIT it closed immediately.

2018-01-18 23:26 GMT-02:00 SE2Dev [email protected]:

I just threw together a small program that logs the signals it receives
just before it exits; It received SIGHUP when I tried to log off (in
Cinnamon). Is the issue perhaps that non-Gnome environments are sending
different signals (e.g. SIGTERM)?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-358837938,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmNKUbyp9hsU1zK8sTYmrOjj9nyFrks5tL-9EgaJpZM4B6Vr_
.

@paulovilli
My system information is as follows:

Debian GNU/Linux 9.3 (stretch)
Linux version 4.9.0-5-amd64
Cinnamon 3.2.7

I just meant I had a simple C program that printed when it received a signal - just so I could figure out what the DE was sending the processes. The code is literally:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

FILE *logfile = NULL;

#define LOG(...)         \
    printf(__VA_ARGS__); \
    fprintf(logfile, __VA_ARGS__)

void startup(void)
{
    logfile = fopen("log.txt", "w");
}

int shutdown(int exit_code = EXIT_SUCCESS)
{
    LOG("[NOTE]: exiting...\n");
    fflush(logfile);
    fclose(logfile);
    return exit_code;
}

void signal_callback_handler(int signum)
{
    LOG("[SIGNAL]: %d\n", signum);
    int retn_code = shutdown(signum);

    // This can be removed / replaced if you want to control when the program actually exists
    // e.g. if you wanted to see if the system sends more aggressive signals after a period of time
    exit(retn_code);
}

int main()
{
    startup();

    // Let's just register the callback handler for all possible signals
    for (int sig = 1; sig < _NSIG; sig++)
    {
        signal(sig, signal_callback_handler);
    }

    for (int i = 0;; i++)
    {
        // Print a line every so often so we know the program was actually running
        LOG("[IDLE]: %d\n", i);
        sleep(1);
    }

    return shutdown();
}

I'm curious what this will print for Gnome - since the issue doesn't seem to occur with Gnome.

The cloudsync isn't the only thing to "block" Steam. Crashuploads for example also cause this (uploads to crash.steampowered.com). It's a creepy little background service running with steam that calls home whenever something breaks (files are in /tmp/dumps for the curious). Since it's yet another host valve doesn't enable ssl on, interception is trivial. Point is Steam will block while it tries.

The other thing to consider is not all signals are delivered in realtime, which means they can block both in an interactive shell and background. So you can end up sending SIGINT all you want for example, it won't
matter if the process is sleeping or blocked on something else.

There is no magic bullet, shutdowns are hard. Anyone whose had to deal with NFS knows this :) I'd rather window managers tell me what process is still blocked then blindly kill things. We have runlevels and different signals for a reason.

At any rate there are threads like this pointing fingers at more general problem not unique to Steam.

Is it possible to find out if Steam is doing a permanent block (inhibit
block) instead of a temporary one (inhibit delay) in reply to being asked
to exit (by means of SIGHUP/SIGINT/SIGTERM or whatever X11 window closing
comands it actually receives)?

Do those issued signals and corresponding blocks get logged somewhere? Is
there a way to monitor it?

Maybe STEAM is handling its signal by using inhibit(block) instead of
inhibit(delay)?
https://www.freedesktop.org/wiki/Software/systemd/inhibit/

If that is the case then either:

1- it is using inhibit(delay) at first and then changing to inhibit(block)
when that dialog window comes up expecting user interaction...

...this could mean if it just waits 2 seconds longer before that window
comes up most users would stop having issues.

or
2- it is just treating itself like an essential piece of software and using
inhibit(block) right from the start...

...this might explain why I noticed no other software ever gets closed
before the shutdown sequence is aborted?

Again, all conjecture from my part, I am no expert at all :(

On Jan 19, 2018 09:30, "h1z1" [email protected] wrote:

The cloudsync isn't the only thing to "block" Steam. Crashuploads for
example also cause this (uploads to crash.steampowered.com). It's a
creepy little background service running with steam that calls home
whenever something breaks (files are in /tmp/dumps for the curious). Since
it's yet another host valve doesn't enable ssl on, interception is trivial.
Point is Steam will block while it tries.

The other thing to consider is not all signals are delivered in realtime,
which means they can block both in an interactive shell and background. So
you can end up sending SIGINT all you want for example, it won't
matter if the process is sleeping or blocked on something else.

There is no magic bullet, shutdowns are hard. Anyone whose had to deal
with NFS knows this :) I'd rather window managers tell me what process is
still blocked then blindly kill things. We have runlevels and different
signals for a reason.

At any rate there are threads like this
https://bbs.archlinux.org/viewtopic.php?id=179489 pointing fingers at
more general problem not unique to Steam.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-358940519,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmKOMw97ly7LDLJevdPoSmRdzRy2Jks5tMHy5gaJpZM4B6Vr_
.

The worst part of all this is that absolutely nothing has been proposed by the Steam developers since the opening of the issue.

The worst part of all this is that absolutely nothing has been proposed by the Steam developers since the opening of the issue.

I've noticed that Valve sometimes ignores UI bugs(this is somewhat a UI bug, I guess) when a major version is planned to come out soon that completely overhauls the UI. No need to fix the bug if it isn't even present in the overhaul. See: Dota 2 when the new in-game HUD came out.
Valve has hinted that it's redesigning the look of Steam's interface.

I've noticed that Valve sometimes ignores UI bugs(this is somewhat a UI bug, I guess) when a major version is planned to come out soon that completely overhauls the UI.

"Meh... we're going to redo that in 4 or 5 years... ignore their rather large problem until then. What are they going to do? Install Desura?!? lol"

The new client Beta should fix this, can people affected re-test?
http://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1655505073049286411

It fixed it for me using Plasma!

Thanks!

On Thu, Jan 25, 2018 at 10:55 PM Pierre-Loup A. Griffais <
[email protected]> wrote:

The new client Beta should fix this, can people affected re-test?

http://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1655505073049286411

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-360699213,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABkeggUML6Ieoj2nZ1whdFxOUBSXvgWSks5tOXbygaJpZM4B6Vr_
.

The latest beta update fixed the issue for me!

Operating System Version:
    "Arch Linux" (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.14.15-1-ARCH
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11906000
    X Window Manager:  KWin
    Steam Runtime Version:  <Runtime disabled>

Latest Beta fixes the issue for me too. Arch + XFCE here, using native runtime.

Beta client on XFCE (Debian) and shutdown works normally again.

Thank you very much for the developers for finding a fix for this!

Shutdown still takes about 30 seconds on Cinnamon. Cinnamon notices an "unknown" program is trying to shutdown, steam closes in the tray, and then the desktop icons disappear. About 30 seconds later the desktop exits.

Fix works on Xubuntu.

OK this looks good. But what's the point of auto-closing Steam when the shutdown menu appears under GNOME?
See: https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-325685239

Fixed for me on Kubuntu 17.10. Before this gets closed and forgotten forever, would you mind disclosing what the fix was? I'm sure other developers could benefit from the insight.

@Zerophase That's a normal function of any modern desktop environment, there's a lot going on that needs to be cleanly shutdown. We haven't been able to just turn off the computer since the Win 3.x days.

@bjwest I definitely get that. It still takes a ton longer to shut the desktop down then if I had manually exited steam before shutting down. I could understand syncing slowing the process down, but that isn't running since I don't have any games installed.

On windows steam shuts down fairly fast.

I just think it's worth looking in on Cinnamon to see if there are any other issues delaying shutdown.

I have a Phenom II x4 965 running Linux Mint Cinnamon 18.3 with kernel
4.13.0-32, all freshly updated, with a AMD HD7770 GPU with no proprietary
drivers installed (actually the most recent AMD CPU microcode yes, but none
for the GPU):
https://gist.github.com/anonymous/1feaa7063988e021d2b3b8c196f10846

I have not received the update with the fix yet. I'm not using steam beta.
I asked Steam to check for an update but it says there is none. Was it
supposed to have arrived yet?
Steam client version is built 15/dec/2017 11:47:57, API v017 and package
v1513371133.

@Zerophase
I timed my computer shutting down right now so I can have a baseline to
compare when the fix comes in... First shutdown attempt takes 2sec to close
Steam (tray icon disappearing) and second attempt issued 1sec later takes
6sec to power off the PC.

Thanks @kisak-valve for the clarification!

I'll post back the results about shutdown timing in Cinnamon.

If it increases notably should me and @Zerophase keep talking about it here
or open a new issue and reference this one?

@paulovilli Hmm, I'm going to have to time my actual shutdown time, but it takes me significantly longer. (when not closing steam manually) 2 seconds to close the Steam icon, and at the 30 second mark the desktop exits.

I have a i7-5960X (using the latest microcode) running kernel linux-ck 4.14.15-2, and a 660ti with the NVidia proprietary drivers.
I'm using steam-native-runtime, and have the latest beta installed.

Same issue here
Manjaro Linux
KDE Plasma 5.11.5
KDE Frameworks 5.42.0
QA Vesion: 5.10.0
Kerlen: 4.14.14-1-MANJARO
64 bit archetecture
CPU: Intel I5-2500k.

Shutdown is completely cancelled. (logout canceled by plasma)

@Dinoraptor101: Problem is fixed in Steam beta (at least for me), either wait till the fix reaches stable or switch to beta in the Steam settings.

Steam beta update seems to have resolved or worked around the issue for me. Shutdown takes about 3-5 seconds longer to leave the desktop session, but it doesn't get cancelled.
Mint 18.2 / KDE Plasma 5.8.8 / Linux 4.8.0-53-generic amd64

@Zerophase and @kisak-valve

I have tested Steam Beta today and the fix works (Steam no longer aborts
shutdown sequence) but there is indeed something wrong with it taking so
long to shutdown now...

I timed it to 38 seconds now, of which only 5 are before Steam's tray icon
disappears and almost all of it is staring at the desktop with barely no
signs that the shutdown sequence is still running.

Just as a reminder, I have posted a week ago about how I timed my computer
shutting down to have a baseline to compare when the fix came in... First
shutdown attempt took 2sec to close Steam (tray icon disappearing) and
second attempt issued 1sec later took 6sec to power off the PC. So even
counting the time lost with a secondary human interaction it took a lot
less time to shutdown before the beta fix.

I will try to post back tomorrow after testing other kernel versions to see
if there is any relation, though it seems unlikely.

Just to make it clear, the fix works. It just needs polishing to improve
the speed of shutdown which got a bit too long on LM Cinnamon 18.3
(apparently only there). Should we open a new issue and reference this one
or just keep posting here about it?

Distro: Linux Mint Cinnamon 18.3
Kernel: Ubuntu Kernel 4.13.0-32 (LM 18 is based on Ubuntu 16.04 repos so
this is the latest HWE kernel available from kernel.ubuntu.org)
CPU: Phenom-II x4 (with latest AMD CPU microcode installed - version
2.20160316.1)
GPU: AMD HD7770 (with no proprietary drivers)
No PPAs installed
Steam: beta - jan/25/2018 21:25:07
Steam API: v018
Steam package: 1516948201
https://gist.github.com/anonymous/1feaa7063988e021d2b3b8c196f10846

2018-02-04 19:06 GMT-02:00 outfrost [email protected]:

Steam beta update seems to have resolved or worked around the issue for
me. Shutdown takes about 3-5 seconds longer to leave the desktop session,
but it doesn't get cancelled.
Mint 18.2 / KDE Plasma 5.8.8 / Linux 4.8.0-53-generic amd64

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-362939622,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmK09ypVe4O0H77o2rOPli1unLXGTks5tRhu8gaJpZM4B6Vr_
.

@Photon89 Thank you for prompt reply, I'll let you know if I face any further issues.

Thank you Valve!

Signing in for Beta worked fine for me.

Manjaro - KDE Plasma 5

For anyone experiencing much longer (+20/30 seconds) shutdown times after
the fix for this issue, I've just opened a new follow-up issue here:
https://github.com/ValveSoftware/steam-for-linux/issues/5379#issue-295363828

(so far only Linux Mint Cinnamon is reportedly affected)

2018-02-06 9:52 GMT-02:00 athordan [email protected]:

Thank you Valve!
Signing in for Beta worked fine for me.
Manjaro - KDE Plasma 5

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-363399964,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmI-4WghVVuhWDN87gcG5MA8noQwTks5tSD0OgaJpZM4B6Vr_
.

Can confirm, beta now lets Cinnamon (Linux Mint) shut down, thanks!

It does however make Cinnamon pop up a box saying that it's waiting on an unknown program to shut down, so there is other issues, maybe for #5379.

I can also confirm that the beta version allows shutdown for me (Linux Mint + Cinnamon), but I also seem to suffering from issue #5379 (same as @paulovilli and @mikerm19)

Like mikerm19 said:
Can confirm, beta now lets Cinnamon (Linux Mint 18.3 Cinnamon) shut down, thanks!

It does however make Cinnamon pop up a box saying that it's waiting on an unknown program to shut down

~$ steam
....
Refresh rate: 1
Refresh rate: 1
Refresh rate: 1
[2018-02-28 17:09:25] Shutdown

...silence from the terminal/unknown program box/system "idle" time...
OS shuts down

It is finally fixed ! Kubuntu 17.10 latest steam client !

18.04.2018
Ubuntu Mate 17.10 x64

Steam prevents my Laptop to go into standby.

hey there @Martin!

What you describe is a different issue from what this bug was about.

I did a quick search for issues involving system standby and found none was
similar either:
https://github.com/ValveSoftware/steam-for-linux/search?q=standby&type=Issues

This aborted powerdown issue did pop up on the search, then 2 issues about
NOT preventing standby while on big picture mode/using xbox controller.

I suggest you open a new issue.

Just be sure to give the issue an accurate and detailed description, and
give all requested info (a suggested issue report layout will appear when
you create it).

PS: I am not a Valve developer, just a user trying to help.

On Wed, Apr 18, 2018, 18:24 Martin Dünkelmann [email protected]
wrote:

18.04.2018
Ubuntu Mate 17.10 x64

Steam prevents my Laptop to go into standby.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/steam-for-linux/issues/3301#issuecomment-382534184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AaXkmIcsxZnB5U4iJ-ZqnJpUwIwxD65Fks5tp68DgaJpZM4B6Vr_
.