I agree. Standards should be supported.
Any news on this at all?
Huge +1. When steam ignores SIGTERM, the whole system, during shutdown, waits for Steam to exit, before killing it.
It's been 3 years, and no response on such a simple request, that's based on standards for the operating system.
I recently wanted to handle properly shutting down steam on my computer through a custom daemon tool. You can't do it. Steam won't allow it.
Why is this issue not even been responded too? SIGTERM is a standard basic mechanism.
If there are technical hurdles to be surpassed, posting such answers here would be of benefit to the community and Linux game developers, as they can design for a spec Valve could release.
Please post a technical synopsis of the challenges implementing this would face.
I bet it'll be another 5-10 years before Valve even bothers to look at this. Y'know how these things go.
I can't believe they still haven't fixed this, confirming that on all my machines, if steam is running and I shutdown the entire system hangs for 30 seconds while it waits for steam to shutdown first.
this is related to #3301 and possibly a duplicate
also:
https://github.com/linuxmint/Cinnamon/issues/3752
They probably just don't care. This is a very minor issue that doesn't actually affect many people. It's a question of convention compliance, not something that actively makes users' lives worse.
In other words, welcome to enterprise proprietary software development. Fuck platform-specific conventions, no one cares. I doubt most linux users would even care about this. How sad.
@fbt I'm doubtful that this "doesn't actually affect many people", unless other distros don't bother to wait for processes to exit, and/or have created workarounds for this problem.
More likely, the people that are affected by this issue wouldn't know why this is happening (since it does not directly reveal itself or show its own flaws during shutdown), and wouldn't know to look for this issue.
And in general, this whole issue gives me a headache because of how long I have to wait to shut down or reboot my computer, so I stopped using Steam for Linux altogether, and decided to use its (more-or-less equally buggy) web-based chat.
Quite disappointing how Valve announced its support for Linux, but never really bothered to go through with it fully and just stopped bothering somewhere in the middle of "nonexistent support" and "adequate support".
@SEAPUNK well I do have other processes that won't die properly on a SIGTERM, which slows down my shutdown time (although it's 30 sec. vs the default of 90 for systemd :) ), and I doubt a lot of users actually realise that it's Steam that is the problem for their shutdown times.
But yes, the shutdown procedure relying on SIGTERM (and we actually have to) problem is a much better argument than just “conventions yo”, true.
@fbt I've never had any other process that did this to me.
Assuming normal everyday usage: internet browser, music player, mail browser, office suite and the DE of choice and all their "extras" (file manager, image viewer, blah blah blah), only Steam out of that large set of software doesn't stop on SIGTERM. Unless the software that you use that doesn't stop on SIGTERM is an everyday tool that many others would use, I would consider your argument a much more narrow edge case to warrant a counterargument to the importance of this issue.
But I digress.
@fbt - Actually I bet most people don't notice this bug because steam crashes every so often, so its already closed, and many of us Linux desktop users are always running, with up times into the 150+ days (me). Often I just close out of it for resources
I was looking into it because I'm working on a "Steam launching supervisor over DBUS" so I can hack my personal edge case. I want to use xrandr to adjust my displays to 1080p single head, when launching steam. So that steam link streaming is less painful. (launch from my cell phone, or something from the living room to play games)
It felt like the right path to create a daemon for launching and controlling steam.
I suspect the issue might be related to child processes, most of the games they have aren't really designed to be fully integrated into a "console" or "supervised" experience. I wonder if the games steam launches respond to a SIGTERM
How would a game launched through steam need to react to a SIGTERM, like if steam gets the SIGTERM and then the game gets it ... do we save state? drop dead? wait for user input?
Steam on Linux likely needs to be a full desktop environment in order to fully overtake the game applications. With compositing window manager (something like gnome)
ohh that explains why my logouts take so long.
i usualy shut down via systemctl poweroff, thatone goes instantly.. maybe i shouldnt use that.
but shutting down from DE waits super long.
@triage-valve any reason why has still not been fixed? This seems trivial to me.
As noted in #4771, the client should also respond to SIGINT.
Closing as fixed in the 2017-01-05 steam beta client update. SIGINT also closed steam in my test.
Awesome, thank you!
Wow. Didn't actually expect this. Thanks, maybe my desktop system will not wait 30 seconds on reboot every time I forgot to kill Steam manually now! :)
this issue was NOT resolved, mint 18.1 mate, still hangs for 30 seconds on shutdown if steam is open
Nothing extracted yet.
[fbt@cetaganda ~]$ cat .steam/steam.pid
5875
[fbt@cetaganda ~]$ ps aux | grep 5875
fbt 5875 3.6 1.5 619964 259296 pts/2 Sl 21:09 0:07 /home/trash/steam/ubuntu12_32/steam
[fbt@cetaganda ~]$ kill 5875
SIGTERM doesn't have any effect on the main steam process.
Considering that SIGTERM is the default kill signal that is supposed to be a way to politely ask a process to clean up and exit, it should work on steam.