Thanks, my responses in-line below
(also restored some of the earlier that was removed from original,
and included full original at tail end of this email):
On Fri, Nov 22, 2024 at 5:02 AM Max Nikulin <
manikulin@gmail.com> wrote:
On 22/11/2024 13:57, Michael Paoli wrote:
all network activity ceases (very bad as this system also operates as
server!)
seems to be a very deep form of sleep, the only things I can do at that
point that at all gets it to respond:
<Control><Alt><Delete> - which does a warm reboot
Does not like suspend to RAM or suspend to disk (hibernate). It
resembles graphics issues. Can you connect to this machine using ssh?
It's way beyond graphic issues, can't ping, ssh, etc. - normally can
ssh fine, runs web server, DNS server, etc. - all goes unresponsive.
Try after reboot or power cycle as root
Been through many reboots / power cycles - has not helped at all.
journalctl -b -1 -e
journalctl is right out presently
Do still have those log files though,
I'll see if I can find anything useful/informative in them
(e.g. via other host(s) where I have journalctl available)
Likewise I want to check more thoroughly the audit log files,
see if I can find anything that's triggering the apparently S3 sleep.
Also changed from systemd to sysvinit (installed: sysvinit-core,
removed: systemd-sysv systemd):
Problem still persists
it may provide more details than /var/log/syslog files.
And notice "IdleAction=" in logind.conf(5) for a case that it is really suspend.
man page indicates IdleAction defaults to ignore:
$ man 5 logind.conf | sed -ne '/IdleAction=$/{N;N;N;N;p;q}'
IdleAction=
Configures the action to take when the system is idle. Takes one of
"ignore", "poweroff", "reboot", "halt", "kexec", "suspend",
"hibernate", "hybrid-sleep", "suspend-then-hibernate", and "lock".
Defaults to "ignore".
$
And from my earlier, all the non-default settings I have for login.conf:
/etc/systemd/{login,sleep}.conf* all files thereunder, lines other
than blank/empty and comment lines:
# ( t="$(/bin/echo -en '\011')" && cd /etc/systemd &&
find {logind,sleep}.conf* -follow -type f ! -size 0 \
-exec grep -a -e "^[$t ]*[^$t #]" \{\} /dev/null \;)
logind.conf:[Login]
logind.conf:HandleLidSwitch=ignore
logind.conf:HandleLidSwitchExternalPower=ignore
logind.conf:HandleLidSwitchDocked=ignore
logind.conf.d/logind.conf:[Login]
logind.conf.d/logind.conf:HandleLidSwitch=ignore
logind.conf.d/logind.conf:HandleLidSwitchExternalPower=ignore
logind.conf.dpkg-dist:[Login]
sleep.conf:[Sleep]
sleep.conf.d/nosuspend.conf:[Sleep]
sleep.conf.d/nosuspend.conf:AllowSuspend=no
sleep.conf.d/nosuspend.conf:AllowHibernation=no
sleep.conf.d/nosuspend.conf:AllowSuspendThenHibernate=no
sleep.conf.d/nosuspend.conf:AllowHybridSleep=no
Earlier configuration from last of Debian 10 on 2024-05-13 before
upgrading to Debian 11 and then Debian 12 (completed on
2024-05-14):
# (
t="$(/bin/echo -en '\011')" &&
xz=~root/tmp/10.13_to_11.9/etc,var_lib_dpkg,var_lib_apt_ &&
xz="$xz"'extended_states.tar.xz' &&
files=$(xz -d < $xz | tar -tf - etc/systemd |
grep -a -F -e logind -e sleep | grep -v '\.dpkg-dist$') &&
set -- $files && for f; do
echo "$f:"
xz -d < $xz | tar -O -xf - $f | grep -a -e "^[$t ]*[^$t #]"
done
)
etc/systemd/sleep.conf:
[Sleep]
etc/systemd/logind.conf:
[Login]
HandleLidSwitch=ignore
And that very last bit above what I had on Debian 10
(through 2024-05-13, which never had the problem),
Started with same on Debian 12, but added lots more
in attempts to stop any and all manner of
sleep/suspend/hibernate.
My full earlier:
https://lists.debian.org/debian-user/2024/11/msg00590.html
How do I disable all manner of sleep/suspend/hibernate on Debian 12?
I really don't want it doing any sleep/suspend/hibernate (I'm okay with explicitly manually triggering it, but I don't even need that).
Symptoms/issue/background:
Was a non-issue on Debian 10 (sleep/hibernate would only occur if I
manually explicitly triggered it).
After upgrade: Debian 10-->11-->12, now it's a major problem.
Seems to correlate to lid closure, but can't 100% confirm that (but has
thus far never happened with the lid open and have been on Debian 12
since 2024-05-14)
seems it's intermittent, as far as I can tell - sometimes goes up to
many days, perhaps a week or more without issue, other times the
problem occurs multiple times per day, and sometimes in (well) under 15
minutes of lid closure, perhaps as quickly as only a few minutes or
less with lid closed (and sometimes seems to happen immediately upon
lid closure).
When it happens (symptoms, etc.);
screen goes black/blanked and won't resume.
all network activity ceases (very bad as this system also operates as
server!)
unable to resume with any kind of keyboard activity*
seems to be a very deep form of sleep, the only things I can do at that
point that at all gets it to respond:
<Control><Alt><Delete> - which does a warm reboot
power cycle it via power button - which does cold boot (no variations
on length of press do anything else - just long press powers it
down).
remove power (and it goes down cold - laptop battery no longer holds
charge and has been that way for many years now - cannot withstand so
much as even a full second of power interruption).
what it shows in the logs - about all I've been able to find is this:
but without any more details as to what's triggering it or how:
ACPI: PM: Preparing to enter system sleep state S3
That's found in the /var/log/{kern.log,syslog}* files
*haven't tried all manner of Magic SysRq keys, as I'm not aware any
which would unblank the screen and/or resume from any manner of
sleep/suspend/hibernate
Things I've tried, and yet the problem persists:
reviewed
https://wiki.debian.org/Suspend
X11:
I'm not running Gnome nor KDE, no DE nor chooser/greeter or the like.
$ ps axlwwww | perl -ne '/[Gg]nome|[Kk]DE/i || $.==1 and print $_;'
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
5 0 38 2 20 0 0 0 - S ?
0:00 [kdevtmpfs]
0 1003 7853 1 20 0 161640 9512 do_sys Sl ?
0:00 /usr/libexec/at-spi2-registryd --use-gnome-session
0 1003 7949 1 20 0 235576 8716 do_sys SLl ?
0:00 /usr/bin/gnome-keyring-daemon --start --foreground
--components=secrets
I typically just fire up bare X and a WM (and the case for above):
startx -- -retro &
fvwm &
Added to ~/.xinitrc
xset dpms 0 0 0
xset -dpms
xset s default
xset s noblank
xset s off
xset s noexpose
xset s reset
xset s 600 600
And that now shows:
$ xset q |
sed -ne '
/^Screen Saver:$/{N;N;p;d}
/^DPMS (Energy Star):$/{N;N;N;p;q}
'
Screen Saver:
prefer blanking: no allow exposures: no
timeout: 600 cycle: 600
Yet the problem persists.
Was on systemd, did:
# systemctl mask sleep.target suspend.target hibernate.target \
hybrid-sleep.target
Problem persists.
/etc/systemd/{login,sleep}.conf* all files thereunder, lines other
than blank/empty and comment lines:
# ( t="$(/bin/echo -en '\011')" && cd /etc/systemd &&
find {logind,sleep}.conf* -follow -type f ! -size 0 \
-exec grep -a -e "^[$t ]*[^$t #]" \{\} /dev/null \;)
logind.conf:[Login]
logind.conf:HandleLidSwitch=ignore
logind.conf:HandleLidSwitchExternalPower=ignore
logind.conf:HandleLidSwitchDocked=ignore
logind.conf.d/logind.conf:[Login]
logind.conf.d/logind.conf:HandleLidSwitch=ignore
logind.conf.d/logind.conf:HandleLidSwitchExternalPower=ignore
logind.conf.dpkg-dist:[Login]
sleep.conf:[Sleep]
sleep.conf.d/nosuspend.conf:[Sleep]
sleep.conf.d/nosuspend.conf:AllowSuspend=no
sleep.conf.d/nosuspend.conf:AllowHibernation=no
sleep.conf.d/nosuspend.conf:AllowSuspendThenHibernate=no
sleep.conf.d/nosuspend.conf:AllowHybridSleep=no
Earlier configuration from last of Debian 10 on 2024-05-13 before
upgrading to Debian 11 and then Debian 12 (completed on
2024-05-14):
# (
t="$(/bin/echo -en '\011')" &&
xz=~root/tmp/10.13_to_11.9/etc,var_lib_dpkg,var_lib_apt_ &&
xz="$xz"'extended_states.tar.xz' &&
files=$(xz -d < $xz | tar -tf - etc/systemd |
grep -a -F -e logind -e sleep | grep -v '\.dpkg-dist$') &&
set -- $files && for f; do
echo "$f:"
xz -d < $xz | tar -O -xf - $f | grep -a -e "^[$t ]*[^$t #]"
done
)
etc/systemd/sleep.conf:
[Sleep]
etc/systemd/logind.conf:
[Login]
HandleLidSwitch=ignore
And through 2024-05-13 on Debian 10 (and even years before that and
earlier Debian versions before that), that was sufficient to avoid
any flavor of sleep/suspend/hibernate unless I manually commanded
it, at least as far as I recall for any specific configuration I
did regarding that (do have all the earlier /etc files if there's
need to review, also listing of packages, from before each major
version upgrade - per Debian's standard recommendations on things
to specifically have backed up prior to major version upgrades).
Also changed from systemd to sysvinit (installed: sysvinit-core,
removed: systemd-sysv systemd):
Problem still persists:
Initially, noticed one significant difference:
closing lid system almost instantly went to (deep) sleep, but
opening lid it resumed. Traced that to elogind configuration
issue. Reconfigured elogind, restarted elogind, that behavior was
then gone (closing lid no longer immediately put system to sleep),
but the original problem still remains. elogind configuration:
$ ( t="$(/bin/echo -en '\011')" && for f in $(
find /etc/*elogin* -type f -print | sort); do echo "$f:"
< "$f" grep -a -e "^[$t ]*[^$t #]"; done)
/etc/elogind/login.conf.d/logind.conf:
[Login]
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore
PowerKeyIgnoreInhibited=yes
SuspendKeyIgnoreInhibited=yes
HibernateKeyIgnoreInhibited=yes
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
AllowPowerOffInterrupts=yes
BroadcastPowerOffInterrupts=no
AllowSuspendInterrupts=yes
BroadcastSuspendInterrupts=no
SuspendState=
HibernateState=
HibernateMode=
HybridSleepState=
HybridSleepMode=
/etc/elogind/logind.conf:
[Login]
RemoveIPC=no
[Sleep]
I also, earlier (a few weeks back or so), removed, to the extent
feasible, most any and all
power management / sleep / suspend / hibernate related packages that I
could (mostly notwithstanding some reverse dependencies)
Hardware:
Dell Inc.
Reg Model P10E
Reg Type P10E001
19.5V 12.3A
JSD2 XXX
DP/N 3HP1J A00
SERVICE TAG FWRXDX1
EXPRESS SERVICE CODE 34633559989
Dell Precision M6600
Modifications/changes on that hardware:
Removed the HDD, replaced with SSD, added 2nd SSD, all years ago,
one of the SSDs failed a few weeks ago, but long after start of the
issue. Also years ago, doubled the RAM from 8GiB to 16 GiB. And as
noted above, battery has been very dead a very long time (can't no
longer even hold enough charge to keep the computer running for a full
second).
Next steps? In addition to asking for some help from the Debian wisdom,
etc. (please, and thanks), I also plan to compare the packages that were installed on Debian 10 prior to upgrade to 11, to those presently
installed on 12 - and see if from that I'm able to identify anything
(and/or its configuration thereof) that may be problematic. I'll also
continue to look at packages (adding, reconfiguring, and/or removing)
that may solve the issue and/or help point to specific origin of the
issue.
Would love to get to the bottom of this and get this resolved. :-)
And then I/you and/or others can add the additional relevant information
to
https://wiki.debian.org/Suspend
Thanks!
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)