Or, letting the screen rest to avoid burn-in and not killing your services
One the ideas I’ve been kicking around lately is whether or not to leave OpenMediaVault behind in favor of a vanilla Fedora 30 server on my personal NAS. The main reason for going with OpenMediaVault in the first place was that I wanted an easy to configure Samba server. However, as I’ve adopted Linux full-time outside of gaming, Samba is becoming less and less of a requirement and SFTP is filling in the gap — quite nicely.
The testing phase began when I decided to fire up an older laptop and connect up a couple of USB hard disks to act as my storage. The idea is that I would get all the planning, like scripts and cron jobs, figured out before I ever deploy seriously. I knew I’d run into issues, especially since I’m more of a Debian/Ubuntu guy, but even better, I’ll get reacquainted with the way the Red Hat/Fedora community does things.
I plan on keeping track of my experiences with posts when I have to do things out of the ordinary, and maybe a few of the ordinary things, too.
One of those not-ordinary things has already cropped up. The lid, while open, was preventing the screen from turning off. This wasn’t a big deal, I thought, I’ll just close the lid! So, I try it, head back to my ssh session, and realize it’s died. I check the laptop. Asleep. I open the lid, and it springs back to life! ssh can resume! I realize I have to disable suspend on close, but since this was the server edition, which has no GUI, I had to figure out how to do this from the Terminal. Here’s what I did to accomplish that:
- Login and
sudo vi /etc/systemd/logind.conf - Find the line
HandleLidSwitch=ignoreand uncomment it (remove the#at the beginning of the line). If for some reason the line isn’t there, add it to the bottom of the file. Write and quit. - Restart the systemd daemon with
sudo systemctl restart systemd-logind
I had honestly expected it to be a bit more involved, but that was it! Close your lid with confidence!
Thanks man!
Of course! Glad to help!
Thanks heaps. I also thought this would be quite difficult and had been putting off even looking. A quick search on the net came up with your post , clear and concise, and bingo. I can close the screen.
So again, thanks heaps.
I don’t suppose you have investigated laptop wifi ( wlp2s0 in my case ) being “unavailable” when using either nmcli or nmtli ?
eth0 ( eps
So glad you got some use out of it. Was driving me crazy until I figured it out.
If nmcli doesn’t see it, then it’s considered “unmanaged.” Lots of factors here, but this is a good resource to start with.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/getting-started-with-nmcli_configuring-and-managing-networking
I’ll consider writing a post about how to let Network Manager handle connections.
Thanks for publishing this tip, it was just what I needed for my Amahi installation on a laptop. (Amahi is a home server, based on Fedora 27.)
Darn. Didn’t work for me on Fedora 35, worse, restarting the service logged me out and caused me to lose two days worth of ongoing computation. 🙁
Ah, I’m sorry to hear that! I wonder if things have changed since Fedora 30. I might give this a test on 35 soon to see if I can make some updates to this article.
Working fine on F36, thank you!
I guess the only thing I’d modify would be
sudo cp /etc/systemd/logind.conf /etc/systemd/logind.conf.bak
first in case things don’t go to plan.
I think we are all in the habit of doing this ourselves, but if you’re following instructions, it’s easy to omit.
works perfectly on Fedora 35 Server
Leo,
I’ve no doubt that this has worked for you and earlier commenters, but I can’t figure out why. As I understand it, all these commented-out lines are the default values already, so there would be no point in uncommenting them unless you are going to change them. Merely uncommenting a line would not change anything, unless there has already been a change somewhere else.