系统似乎在一夜之间重启过;之前打开的应用程序全部关闭,就像系统重启过一样,但没有重启的迹象

系统似乎在一夜之间重启过;之前打开的应用程序全部关闭,就像系统重启过一样,但没有重启的迹象
  • 处理器:英特尔(R) 酷睿(TM) i7-10700KF CPU @ 3.80GHz
  • 记忆:32770MB(已使用 4395MB)
  • 母板: PRIME Z490-A
  • 显卡:RTX 2060
  • 操作系统: Pop!_OS 22.04 LTS

过去两天,当我从前一天晚上回到我的工作站时(我让系统保持通电状态)我的系统似乎已经重新启动了。

我之前打开的应用程序全部关闭了仿佛系统已重新启动。但我知道它没有重新启动,因为日志是这么说的。

DMESG 显示了一些有趣的东西,但没有关机或启动消息,除非我到达后手动重新启动计算机并发现我的应用程序已关闭且应用程序无法运行或运行不稳定。

我不确定这是什么,但似乎是内存问题。我对我的系统进行了完整的硬件测试,没有发现任何问题。我想知道是否有人可以帮助我诊断这个问题。这是我的DMESG 日志在 Pastebin 上。

请注意,当我早上 7:00-8:00 左右返回工作站时,日志显示我手动重启。由于行为不稳定,我不得不这样做。

以下是 DMESG 日志的最后十几行:

Mar 03 00:00:01.012586 pop-os kernel: audit: type=1400 audit(1677830401.008:63): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=1365188 comm="cupsd" capability=12  capname="net_admin"
Mar 03 07:57:21.044559 pop-os kernel: rfkill: input handler enabled
Mar 03 07:57:22.280555 pop-os kernel: hub 1-6:1.0: USB hub found
Mar 03 07:57:22.280701 pop-os kernel: hub 1-6:1.0: 4 ports detected
Mar 03 07:57:23.648558 pop-os kernel: ntfs3: Unknown parameter 'windows_names'
Mar 03 07:57:23.852585 pop-os kernel: rfkill: input handler disabled
Mar 03 08:04:21.444861 pop-os kernel: rfkill: input handler enabled
Mar 03 08:04:24.060560 pop-os kernel: rfkill: input handler disabled
Mar 03 08:04:51.664560 pop-os kernel: rfkill: input handler enabled
Mar 03 08:04:51.692659 pop-os kernel: EXT4-fs (sdc4): unmounting filesystem.
Mar 03 08:04:51.720558 pop-os kernel: EXT4-fs (sde1): unmounting filesystem.
Mar 03 08:04:53.208616 pop-os systemd-shutdown[1]: Syncing filesystems and block devices.
Mar 03 08:04:53.228718 pop-os systemd-shutdown[1]: Sending SIGTERM to remaining processes...

答案1

关于查找重启完成位置的建议(或者是否有任何软件通过命令导致重启reboot):

  • 使用以下方法查找上次启动时间:who -b, 或uptime(或tuptime -t)以查看启动时间
  • 检查/var/log/messages一下这个时间
  • 在 cron 脚本中搜索重启: grep -re "sudo reboot" /etc/cron.d/
  • 如果绝望,就到处搜索: grep -re "sudo reboot" /etc/ /var/

如果您找不到任何可能导致问题出现的软件,那么您可能应该寻找硬件原因(也许是电源)。

我建议作为第一个硬件测试运行 MemTest86 至少一夜之间。它将测试 RAM,还会测试一般系统功能。还请检查磁盘的 SMART 属性。如果此测试和 MemTest86 测试结果都正常,则这很可能不是您计算机上的硬件错误(但仍有可能来自您的环境)。

答案2

所以@harrymc 的建议使用以下方法测试 RAM:MemTest86答案是。其中一个内存条坏了,这可能是我的问题的原因。晚上的日志由@daniel-b 推荐由于需要筛选的日志条目太多,因此无法得出结论。

但由于这可能是 RAM 问题,日志可能无法帮助我确认应用程序崩溃的问题。我将看看移除坏 RAM 后情况如何。感谢您的帮助!

相关内容