Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)

From: Steve Rikli <sr_at_genyosha.net>
Date: Fri, 11 Nov 2022 03:36:49 UTC
On Thu, Nov 10, 2022 at 10:21:24PM -0500, Alexander Motin wrote:
> On 10.11.2022 15:29, louis.freebsd@xs4all.nl wrote:
> > I am still desperately trying to stop FreeBSD from sleeping, but I
> > simply do not manage.
> > 
> > It is really very annoying that I have to restart the machine every 10
> > minutes, when I am working via SSH.
> > 
> > So if any one has a solution, it would be very much appreciated!
> > 
> > It should ….. be possible to kill / stop ACPI some how 😊
> > 
> > If absolutely not possible in the actual build 😊, a cron job restarting
> > the timer every 5 minutes perhaps !!???
> 
> I've never used it, so just an idea, but there is sysctl
> kern.suspend_blocked that being set to 1 seems should block suspend
> requests.  You may try to set it and see what happen.
> 
> > It is possible perhaps … that GNOME is initiating this, despite that the
> > GUI powersetting is screenblank β€œNEVER”.
> 
> It is not a screen blank.  Gnome site tells:
> https://help.gnome.org/users/gnome-help/stable/power-autosuspend.html.en
> 
> > Whatever is causing the problem, the settings should be such that ^no
> > whatever program^ should not be capable to initiate the sleepmode.
> 
> Does the system suspends if you do not start Gnome?  For example if you boot
> into single-user mode and leave the system there?  It would be the easiest
> test probably.

This sounds somewhat like the Gnome gdm3 behavior that causes some(?)
Linuxes to suspend & sleep after 20 minutes (ymmv?) by default if gdm3
is running. E.g.

https://wiki.debian.org/Suspend

IME it didn't matter if user was logged in to desktop or not, the mere
presence of a running gdm3 process was enough to trigger the behavior
unless it was disabled. My FreeBSD's without gdm3 don't see this.

Obviously there's no Linux systemD in-play here, but along the lines
Alexander suggests, you might try stopping any running gdm3 processes
and see if the sleep behavior persists. That would at least give some
hint as to the vicinity of the problem.

sr.