I have two issues:
– after some time of user inactivity, my F39 Desktop machine goes on suspend
– most often (not always) I am not able to resume form suspend (machine seems to boot, but screen stays blank, and I need to shutdown it)
First question, how do I avoid default suspend?
I just checked that my /etc/systemd/logind.conf is
Are you comfortable with linuc command-lines tools? Diagnosing and fixing issues in linux often needs them. You may want to look at Linux Command to learn more about the command line in Linux.
The first issue is not going away, but has workarounds. See /etc/systemd/sleep.conf, which points you to the man page.
Before retiring I worked in a “large enterprise”. My cubicle was in building renovated a decade ago with a limit of 300 watts per cubile (and circuit breakers in a locked room with a random assignment of cubicles to breakers!). More recent renovations reduced power allocations and increased the density.
My group had “mission critical” software that required a POSIX environment, e.g., linux or macOS. Apple had an advantage that they pay a lot of attention to power demands. Other vendors have started efforts to ensure that systems running linux can be sold in volume to large enterprises.
For your 2nd issue, journalctl collects a massive amount of detail for each boot. It is a command-line tool and very likely has entries related to your issue, but it can take some work to find them. I recommend looking at boots for working and failed resumes to find differences. If those don’t lead you to a fix, you should find a filter using boot number (-b N), priority (-p P), and grep strings (-g string) – these are expained in man journalctl.
Once you find a filter that selects relevant entries, you can post them as pre-formatted text (use the </> button from the top line of the text entry panel).
I suggest using something like journalctl --no-hostname <filters> | cat (we don’t need to see your hostname, and cat wraps the long lines which are commonly generated by journalctl.
The long lines may be an issue by being truncated on-screen on terminals which do not automatically wrap long lines but otherwise do not seem an issue.
The long lines are especially not an issue here when the user uses the </> button so they remain as a long line that can be panned across for reading.
If not using the </> button the long lines are automatically wrapped on the forum.
This is definitely as you are saying. I traveled for 10 days last week and saw the pain to read on slow and old devices. Never less, I took the chance to use my mobile device just as read only one. And focus on helping when I am back on my desktop setup.
As long as nobody makes the work to change the theme for mobile devices in discourse we probably have to live with this restriction.
Back to the topic:
To keep the logs short I love to use the daily error view for my debuggings.
@mario60, did some of the proposals here help you to get along with the suspend issue? Please give feedback and mark the topic which most helped you as solution.
p.s.
You can also let the last parameter away ( -p err ) and simply filter with an other priority or even grep (I love to use -i to use case insensitive patterns).
