In case there is some stateful network connection (eg. TCP, SSH, HTTP, IMAP, ...) it will probably timeout sooner or later. Then it depends on how well the app can detect it and reconnect once resumed again.
And that is probably mostly fine since HTTP is or is supposed to be stateless. IMAP by design can reconnect and one can work around SSH by using MOSH [1] in those cases which is stateless and great for lossy and/or mobile networks.
They do nothing anymore. The OS will not give them any CPU time until they are resumed. No network communication, no redrawing of windows. If they started subprocesses, those might still run; I don't know the details about that.
Sounds like a good idea, especially on applications that you don't need notifications from. I'd love it if suspension could be limited to the awfully bloated web renderer processes and still let the core application handle its background-y application-ish stuff in the background.
The closest option seems to be `resume_every=` [1] which resumes the application so it can handle its accumulated events. All apps are preconfigured with it. [2]
Dangerous to put on your landing page. First, if it gains popularity and more people start looking into it, you will find vulnerabilities or memory leaks, it's just a question of effort and time. Secondly, it invites people to prove you wrong, maybe more than wanted, and once they find something, you're gonna have to eat your shoe.
Maybe something better would be "Security & Performance high priority" or similar, with better wording.
Haha, you're right! I thought that referred to some support contract the developer was offering, but based on the rest of the content of the page (and lack of support contract), I think you're right :)
It's brilliant, for exactly those reasons. If it motivates someone to find flaws, I would happily claim my code is "flawless". When I'm inevitably proven wrong, I can fix the bug / merge the PR and say "Thanks to [contributor]'s hard work and sharp eyes, now the code is completely flawless!" Hopefully, it would motivate even more to prove me wrong. Really smart, on the part of the developers, to say that.
This isn't an unheard-of practice in the software world. BSD has often touted itself as the most secure *NIX-like system on the market today. When someone files a CVE, the developers use it as an excuse to powwow, crush the bug or vuln, and then continue claiming to be best-in-breed.
And yes, that's not necessarily the de-facto behavior of a lot of developers, unfortunately. Projects like Flatpak have hundreds of open issues and vulns, with only a handful of developers actually dedicated to working on it. These people often prioritize features over fixes, and they reap what they sow for it.
This is a really bizarre comment to make, considering BSD has no equivalent to flatpak. Flatpak might only have a handful of developers, on BSD you get nobody trying to fix application-level sandboxing at all. Unless I missed something and there's a new BSD project being worked on here, but I haven't heard anything.
They're both security-oriented, open-source projects with limited numbers of contributors. I'm comparing the way they handle their priorities, and moreover just trying to tie it back to how claiming to be perfectly secure is a pretty regular occurrence. It's not an apples-to-apples comparison, but it doesn't have to be for the sake of this example.
It's especially bad because I can already name a vulnerability. The method used by this program (sending SIGSTOP to the pid in _NET_WM_PID) is inherently broken and can be abused by malicious processes into sending signals to the wrong process, because _NET_WM_PID is set by the client and can be anything. It's completely broken and won't work at all if your process is in a pid namespaced sandbox (e.g. docker container, bwrap, firejail, flatpaks, snaps) because the process inside the namespace doesn't know its global pid.
Suffice to say it's disappointing whenever I see tools built this way, using pids for signaling in a GUI is a really bad idea and should be avoided. A way to fix it on Linux would be to pass pidfds around everywhere, unfortunately that's Linux-only and adoption of it is very slow. Another Linux-only option would be to use the cgroup freezer if that ever gets implemented in cgroupsv2.
No I mentioned two ways it could be done better, it has to use different OS facilities. Of course you are right about the futility of trying to secure anything connected to the X server, a solution based on X11 will probably always have vulnerabilities.
> In Hinduism, the right-facing symbol (clockwise) (卐) is called swastika, symbolizing surya ("sun"), prosperity and good luck, while the left-facing symbol (anti-clockwise) (卍) is called sauwastika, symbolising night or tantric aspects of Kali.
You used to be able to suspend KDE Activities (sorta like a group of running applications - similar to switching to "desktop" in most DEs). So you could have separate activities for different projects. It was very handy. You could have some huge bloated C++ IDE + documentation + whatever in the background somewhere ready to be resumed when you need it. At some point it all got removed though. I have no idea why (and now "Activities" are kinda pointless). My guess is some applications break and they got lots of complaints - but that's just a guess
Firefox (and AFAIK Chrome too) has native APIs for unloading/suspending tabs. I use
[1] auto tab discard to configure background tab unloading after a certain period of time. Works very well, battery usage reduced greatly.
The problem with "discard"ing tabs is that restoring the tab reloads it, leading to an annoying wait and also losing the state that it was in. Neither browser gives a way to just pause the JS analogous to a SIGSTOP, ie whatever next function the JS calls just blocks, or timer events stop being delivered, until an analogous SIGCONT.
This works also on MacOSX, and really saves quite some resources. Even with tab suspenders (The Great Suspender), Chrome still takes quite some resources.
Easy for you to say if you haven't had two generations of your family (and all your friend's families) butchered by the Nazis, and half of your country destroyed. I live in such a place and certainly don't consider it "a problem". Buddhists manage just fine, somehow.
I made a similar thing that's done using KDE's focus signals, forwarded from kwin over dbus.
The benefits of using kwin's signals are that it potentially works also on Wayland. The downside is that it only works on KDE.
I used it to stop Firefox instances that I wasn't using. The quirks are real though, and the clipboard hangup + a remote SSH client combo occasionally made the X session completely unresponsive due to reasons I don't quite remember. The solution was to kill the remote X connection. Another nasty quirk is that switching away from a Jitsi session and back in made the session completely irrecoverable with about 50% chance. Not even a browser restart could help – the sound was permanently gone.
I would not recommend this solution for the faint hearted, except maybe in the milder version where the processes get limited access to CPU using cgroups - but not zero, so that they can't choke and take down other parts of the system.
Nowadays Firefox improved its CPU usage a little, so I'm not using the program, but I might need to come back to it again.
I’d love to have something like this for Gnome on Wayland. Either automatically like this project, or some kind of “pause” button on the title bar. If only there were a couple more hours per day…
I really dislike these "suspend-on-idle" approaches. Developers should "pay their taxes" (see The Old New Thing) and make applications well-behave on idle, rather than forcing by default to suspend everything which is a real annoyance.
Specially in the FLOSS world, I think most programs are actually doing rather nice, since during the powertop era there was some push for people to "pay their taxes". Nowadays it seems that people no longer care as much, but we still have a nice headstart.
I really dislike these "virtual memory" approaches. Developers should "pay their taxes" and make applications well-behave with regard to memory, rather than forcing by default to segfault on every memory access outside of process bounds which is a real annoyance.
This is kind of a broken analogy, since we do usually know that an out-of-bounds memory access is definitely an undesirable thing, but how do you know idle CPU activity is an undesirable thing ?
In fact, the entire complain is because suspending background processes _is_ annoying, and may even lead to data loss.
To put it in another way:
> forcing by default to segfault on every memory access outside of process bounds which is a real annoyance.
Is forcing to segfault a real annoyance ? Can you show me an example of where it is an annoyance ? Do you prefer to let processes continue accessing obviously undefined memory and/or corrupting the memory of other processes or the system ?
On the other hand, suspending a process on idle is an annoyance:
* If it was a service, you've just caused a Denial of Service attack.
* If it was a timer/cron/alarm of some sort, you've just caused it to miss important events -- the user will arrive late to their meeting.
* If it is a client, it suddenly stopped talking to its server, with unknown consequences.
* If it was even a simple editor that is just saving the user document as a background task, you've lost user data.
The analogy works as there is overhead to virtual memory management as well as all the LSMs that have been implemented over time to protect developers from themselves.
That said, you are right about having some reservations about automatically suspending applications. However, it would be nice to have the option. I would like to opt-in to something like this on a case-by-case basis.
> Is forcing to segfault a real annoyance ? Can you show me an example of where it is an annoyance ?
Well, if you're an Amiga programmer you may depend on being able to walk through system memory or memory belonging to other processes. System calls into Amiga EXEC are made by offsets from a base pointer in absolute memory space (it was 4 in old-school AmigaOS). I swear, there are people in the Amiga community who actually believe virtual memory is a short-lived fad, and we will all realize the error of our ways once the Amiga comes again in glory. Or there were ten years ago... I think that hope for Amiga as a viable platform in the current year has dried up by now even among the diehards.
> On the other hand, suspending a process on idle is an annoyance:
No one was talking about blindly suspending processes on idle. XSuspender's job is to suspend X clients, i.e., interactive programs, that aren't being interacted with. And you have fine-grained control over which clients it actually suspends so it doesn't stop your xclock.
I used to do a lot of 16-bit Windows programming, and there was an awful lot of "tax paying". You had to free window, device context, brush, etc. handles as soon as you were finished using them, otherwise you'd blow your GDI heap and other applications would crash -- or worse. When I switched to Win32 and later Unix it was nice to not have to worry about the resources, including memory and window handles, from a crashed app being cleaned up by the system. It's not a license to code sloppily, but it's one less thing to have to think about should something go wrong.
I don't see why power management can't be the same. I don't see why Android can't for instance snapshot the heap of a backgrounded app without a running service attached, and then restore the heap from the snapshot when the app is resumed instead of making the developer save and restore application state by hand onPause() and onResume().
Oh, and "paying your taxes" is doubtless a reference to USA income taxes, where you have to submit a detailed record of your earnings and deductions to the IRS each year, despite the IRS already having this information. In countries with sensible tax codes, the tax service automatically deducts taxes from your paycheck and in most cases only a simple confirmation that the amount deducted is correct is necessary. So there's not actually much need for "paying your taxes" even when it comes to actually paying your taxes.
In an ideal world, yes. In the here and now, this is a solution to a problem which doesn't involve seeing the source code, being a developer, requiring a FOSS OS (after all the main OSes are Windows, macOS, Linux server OSes, Android, and iOS), etc.
However, the framework with kernel signals (which this uses AFAIK SIGSTOP (17) / SIGCONT (19)) is there on Unix systems, if not a bit rigorous.
For example, say I have an e-mail client on a laptop and one on my smartphone. On my laptop, I don't need to know at night that if I receive an e-mail I need a notification LED or even refresh e-mail. It can do that once I restart the laptop. However, on my smartphone, I might be waiting for an important e-mail or I might want to receive an important SMS or say an AMBER alert. My point being, there are different gradations of importance which depend on factors. The interesting part is learning about these patterns. With ML? Or by asking the user? I believe something like macOS and Android already do this with DND mode.
When I start wondering why my laptop fan keeps spinning or why the battery keeps being drained even though I'm not doing anything resource-intensive on the foreground, the culprit usually turns out to be a web browser, or a web page that keeps spinning the browser's wheels for some reason.
I guess that might be a part of the problem: the root cause is often somewhere else than in the (traditional, non-javascript) application that you're running on your desktop. Although I imagine browsers would do something to avoid unnecessary resource use when a page is not active, it's harder to entirely prevent it without potential side effects when the "data" of your program can essentially be an application of its own running within your platform. To make applications behave well on idle, you'd have to involve web developers, and their priorities are ultimately dictated by their bosses and clients, too.
Other than that, I wholeheartedly agree that it would be better to not have code that consumes unnecessary resources in the first place than it would be to try preventing it downstream.
The only other applications that I regularly find using multiple percent of CPU time when not in active use are Thunderbird and Steam. I have no idea what's going on with Thunderbird or why it's doing that. Some other applications may have some unnecessary background activity as well, and it might be nice not to have that, but it's usually not particularly heavy. The powertop era you mention may have helped with that.
I can see in the Activity Monitor that many apps actually are suspended this way: all the Apple stuff like Safari web content, Finder, Xcode, Music, but also quite a long list of 3rd party apps, like Microsoft Office or Sublime Text.
Unfortunately none of the messaging apps (Slack, Signal, WhatsApp) and their content and rendering processes ever seem to nap, nor seem other Electron-based stuff like VS Code. They're all happily eating 1-5% CPU, all day. Shame!
This is yet another example of the advantages of native apps on the Mac platform, part of why Mac users get so upset about hogs like Slack. App Nap has been on the Mac platform for nearly 10 years.
I’m curious why all the Electron apps fail at napping. As per the linked Apple documentation, there’s no need to opt in or call an API or anything, the app is simply required not to be constantly redrawing the window. Is this where they fail, with gifs and blinking cursors? Can’t be that simple, right, or somebody would have fixed it?
And I do know that in general, Chrome is perceived as a resource hog on the Mac, at the expense of great performance. I'm guessing it hasn't been made easy.
I tried to use this for a little bit, but I kept having random issues on things like Telegram and Slack where when it'd gain focus again it couldn't ever keep up with the keyboard as I was typing anymore.
You can do it for sway too. `swaymsg -t subscribe -m '["window"]'` will send you an event every time focus changes, from which you can get the ID and PID of the newly focused window. However the script will have to track the previously-focused-now-unfocused window itself (which the ID is useful for).
Care will also have to be taken to handle the case when focus moves to a container rather than a window.
I use a similar SIGSTOP/SIGCONT script myself, but it's for when I turn my desktop PC's monitors off for the night rather than focus changes. It uses `swaymsg -t subscribe -m '["workspace"]'` for `"move"` events; when windows move to the "NOOP-1" workspace their processes get SIGSTOP'd, and when they move from the "NOOP-1" workspace their processes get SIGCONT'd.
76 comments
[ 0.27 ms ] story [ 140 ms ] thread[1] - https://mosh.org/
[1]: https://kernc.github.io/xsuspender/xsuspender.1.html
[2]: https://github.com/kernc/xsuspender/blob/8949dbee0d489a020c7...
Dangerous to put on your landing page. First, if it gains popularity and more people start looking into it, you will find vulnerabilities or memory leaks, it's just a question of effort and time. Secondly, it invites people to prove you wrong, maybe more than wanted, and once they find something, you're gonna have to eat your shoe.
Maybe something better would be "Security & Performance high priority" or similar, with better wording.
> Guaranteed or your money back! (In case you do find any, please let us know.)
Personally, if they respond with alacrity and transparency then I get to trust them more.
For the average consumer ...
And yes, that's not necessarily the de-facto behavior of a lot of developers, unfortunately. Projects like Flatpak have hundreds of open issues and vulns, with only a handful of developers actually dedicated to working on it. These people often prioritize features over fixes, and they reap what they sow for it.
Suffice to say it's disappointing whenever I see tools built this way, using pids for signaling in a GUI is a really bad idea and should be avoided. A way to fix it on Linux would be to pass pidfds around everywhere, unfortunately that's Linux-only and adoption of it is very slow. Another Linux-only option would be to use the cgroup freezer if that ever gets implemented in cgroupsv2.
It can also pop up an xterm and type ‘kill’ into it.
Not that this isn’t poor design though, but it’s the best one can do.
https://github.com/kernc
And this other user has the same avatar and explicitly says they are buddhist.
https://github.com/neokin
no other signs anywhere I can see that give any cause for concern.
> In Hinduism, the right-facing symbol (clockwise) (卐) is called swastika, symbolizing surya ("sun"), prosperity and good luck, while the left-facing symbol (anti-clockwise) (卍) is called sauwastika, symbolising night or tantric aspects of Kali.
[0] https://en.wikipedia.org/wiki/Swastika
The biggest offender here is the browser. I don't see any room for improvement by this programm here.
[1]: https://addons.mozilla.org/en-US/firefox/addon/auto-tab-disc...
https://github.com/albertz/system-tools/blob/master/bin/chro...
This works also on MacOSX, and really saves quite some resources. Even with tab suspenders (The Great Suspender), Chrome still takes quite some resources.
If it had been rotated 45 degrees you might have an argument for it not being cool.
Using it in a Buddhist or Hindu context is perfectly fine, of course.
But you cannot expect people to see it on a random website without context and be happy with it.
The benefits of using kwin's signals are that it potentially works also on Wayland. The downside is that it only works on KDE.
I used it to stop Firefox instances that I wasn't using. The quirks are real though, and the clipboard hangup + a remote SSH client combo occasionally made the X session completely unresponsive due to reasons I don't quite remember. The solution was to kill the remote X connection. Another nasty quirk is that switching away from a Jitsi session and back in made the session completely irrecoverable with about 50% chance. Not even a browser restart could help – the sound was permanently gone.
I would not recommend this solution for the faint hearted, except maybe in the milder version where the processes get limited access to CPU using cgroups - but not zero, so that they can't choke and take down other parts of the system.
Nowadays Firefox improved its CPU usage a little, so I'm not using the program, but I might need to come back to it again.
Specially in the FLOSS world, I think most programs are actually doing rather nice, since during the powertop era there was some push for people to "pay their taxes". Nowadays it seems that people no longer care as much, but we still have a nice headstart.
In fact, the entire complain is because suspending background processes _is_ annoying, and may even lead to data loss.
To put it in another way:
> forcing by default to segfault on every memory access outside of process bounds which is a real annoyance.
Is forcing to segfault a real annoyance ? Can you show me an example of where it is an annoyance ? Do you prefer to let processes continue accessing obviously undefined memory and/or corrupting the memory of other processes or the system ?
On the other hand, suspending a process on idle is an annoyance:
* If it was a service, you've just caused a Denial of Service attack.
* If it was a timer/cron/alarm of some sort, you've just caused it to miss important events -- the user will arrive late to their meeting.
* If it is a client, it suddenly stopped talking to its server, with unknown consequences.
* If it was even a simple editor that is just saving the user document as a background task, you've lost user data.
That said, you are right about having some reservations about automatically suspending applications. However, it would be nice to have the option. I would like to opt-in to something like this on a case-by-case basis.
Which XSuspender provides via its configuration file.
Well, if you're an Amiga programmer you may depend on being able to walk through system memory or memory belonging to other processes. System calls into Amiga EXEC are made by offsets from a base pointer in absolute memory space (it was 4 in old-school AmigaOS). I swear, there are people in the Amiga community who actually believe virtual memory is a short-lived fad, and we will all realize the error of our ways once the Amiga comes again in glory. Or there were ten years ago... I think that hope for Amiga as a viable platform in the current year has dried up by now even among the diehards.
> On the other hand, suspending a process on idle is an annoyance:
No one was talking about blindly suspending processes on idle. XSuspender's job is to suspend X clients, i.e., interactive programs, that aren't being interacted with. And you have fine-grained control over which clients it actually suspends so it doesn't stop your xclock.
I used to do a lot of 16-bit Windows programming, and there was an awful lot of "tax paying". You had to free window, device context, brush, etc. handles as soon as you were finished using them, otherwise you'd blow your GDI heap and other applications would crash -- or worse. When I switched to Win32 and later Unix it was nice to not have to worry about the resources, including memory and window handles, from a crashed app being cleaned up by the system. It's not a license to code sloppily, but it's one less thing to have to think about should something go wrong.
I don't see why power management can't be the same. I don't see why Android can't for instance snapshot the heap of a backgrounded app without a running service attached, and then restore the heap from the snapshot when the app is resumed instead of making the developer save and restore application state by hand onPause() and onResume().
Oh, and "paying your taxes" is doubtless a reference to USA income taxes, where you have to submit a detailed record of your earnings and deductions to the IRS each year, despite the IRS already having this information. In countries with sensible tax codes, the tax service automatically deducts taxes from your paycheck and in most cases only a simple confirmation that the amount deducted is correct is necessary. So there's not actually much need for "paying your taxes" even when it comes to actually paying your taxes.
However, the framework with kernel signals (which this uses AFAIK SIGSTOP (17) / SIGCONT (19)) is there on Unix systems, if not a bit rigorous.
For example, say I have an e-mail client on a laptop and one on my smartphone. On my laptop, I don't need to know at night that if I receive an e-mail I need a notification LED or even refresh e-mail. It can do that once I restart the laptop. However, on my smartphone, I might be waiting for an important e-mail or I might want to receive an important SMS or say an AMBER alert. My point being, there are different gradations of importance which depend on factors. The interesting part is learning about these patterns. With ML? Or by asking the user? I believe something like macOS and Android already do this with DND mode.
I guess that might be a part of the problem: the root cause is often somewhere else than in the (traditional, non-javascript) application that you're running on your desktop. Although I imagine browsers would do something to avoid unnecessary resource use when a page is not active, it's harder to entirely prevent it without potential side effects when the "data" of your program can essentially be an application of its own running within your platform. To make applications behave well on idle, you'd have to involve web developers, and their priorities are ultimately dictated by their bosses and clients, too.
Other than that, I wholeheartedly agree that it would be better to not have code that consumes unnecessary resources in the first place than it would be to try preventing it downstream.
The only other applications that I regularly find using multiple percent of CPU time when not in active use are Thunderbird and Steam. I have no idea what's going on with Thunderbird or why it's doing that. Some other applications may have some unnecessary background activity as well, and it might be nice not to have that, but it's usually not particularly heavy. The powertop era you mention may have helped with that.
I can see in the Activity Monitor that many apps actually are suspended this way: all the Apple stuff like Safari web content, Finder, Xcode, Music, but also quite a long list of 3rd party apps, like Microsoft Office or Sublime Text.
Unfortunately none of the messaging apps (Slack, Signal, WhatsApp) and their content and rendering processes ever seem to nap, nor seem other Electron-based stuff like VS Code. They're all happily eating 1-5% CPU, all day. Shame!
https://codereview.chromium.org/2914913002/
And I do know that in general, Chrome is perceived as a resource hog on the Mac, at the expense of great performance. I'm guessing it hasn't been made easy.
> - A GNOME Desktop User
Alright, I'll give it a try but only because you've got one of the best fake testimonials I've seen in a while.
- Prevents pasting from clipboard while the selection source process is suspended …
- Won't work in remote X sessions.
- Won't work with Wayland.
…
- Processes that take a long time to shut down after their window already disappears may be stopped in the middle of their termination routines.
See https://wiki.archlinux.org/title/clipboard
- Seems like nobody cares about remote X sessions any longer.
- You could probably work up something with sways ipc by subscribing to workspace focus events and suspending apps in workspaces that are hidden.
- You can avoid this issue with a timeout on actually suspending things.
https://github.com/kernc/xsuspender/blob/92ea5c6dfcb0f79eb10...
[Slack]
match_wm_class_contains = slack
send_signals = false
IIRC, I still had issues with this setting
Care will also have to be taken to handle the case when focus moves to a container rather than a window.
I use a similar SIGSTOP/SIGCONT script myself, but it's for when I turn my desktop PC's monitors off for the night rather than focus changes. It uses `swaymsg -t subscribe -m '["workspace"]'` for `"move"` events; when windows move to the "NOOP-1" workspace their processes get SIGSTOP'd, and when they move from the "NOOP-1" workspace their processes get SIGCONT'd.