兄弟，我太懂这种无日志崩溃的闹心了——本来升级系统是为了修App的bug，结果反而搞出更头疼的死机问题，连日志都不给留线索，真的烦。结合你描述的情况，给你几个排查方向，说不定能找到根源：

• 先排查硬件问题：很多无日志崩溃都是硬件锅，比如内存坏块、硬盘故障或者CPU过热。试试这几个命令：

  • 安装memtester（sudo apt install memtester），然后跑sudo memtester 4G 5（替换成你空闲的内存大小），检测内存是否有问题；
  • 用smartctl -a /dev/sda（把/dev/sda换成你的系统盘）查看硬盘SMART健康状态，重点看Reallocated_Sector_Ct这类指标；
  • 装sensors（sudo apt install lm-sensors），跑sensors看看CPU和显卡的温度，排除过热死机的可能。

• 开启内核调试日志：有时候内核崩溃会把信息输出到早期缓冲区，但默认没保存到日志里。你可以修改GRUB配置试试：

  1. 编辑/etc/default/grub，找到GRUB_CMDLINE_LINUX_DEFAULT这一行，在引号里加上debug earlyprintk=vga,keep；
  2. 执行sudo update-grub更新配置；
  3. 下次如果再崩溃，屏幕上可能会留下内核崩溃的打印信息（如果是桌面机能看到的话，服务器的话可能需要配置串口日志）。

• 检查第三方驱动/内核模块：升级到23.04后，有些非开源驱动（比如NVIDIA显卡驱动、某些网卡驱动）可能和新内核不兼容。你可以：

  • 用lsmod查看当前加载的模块，留意那些非官方的（比如带nvidia字样的）；
  • 暂时换成开源驱动试试（比如NVIDIA换成nouveau），或者卸载可疑模块，看是否还会崩溃。

• 配置systemd持久化日志：默认journalctl可能部分日志存在内存里，崩溃后就丢了。改成磁盘持久化试试：

  1. 编辑/etc/systemd/journald.conf，把Storage=auto改成Storage=persistent；
  2. 执行sudo systemctl restart systemd-journald生效；
  3. 下次崩溃后，再用journalctl -b -1查看上一次启动的日志，说不定能抓到更多线索。

• 排查OOM Killer：有时候内存耗尽导致系统崩溃，但OOM Killer的日志可能藏在dmesg里。下次重启后，试试dmesg | grep -i oom或者journalctl -k | grep -i oom，看看有没有内存耗尽的记录。

• 测试干净启动环境：如果是第三方软件导致的崩溃，试试在干净环境下运行：

  • 重启后进入单用户模式，或者用sudo systemctl list-unit-files --type=service | grep enabled列出所有自启动服务，临时禁用非系统核心的服务（sudo systemctl disable <服务名>），只保留必要的，看是否还会崩溃。

另外，关于auth.log里的空字符，大概率是崩溃时日志写入突然中断，磁盘缓存没来得及刷进文件导致的，不一定是auth服务本身的问题，重点还是找系统崩溃的根源。

备注：内容来源于stack exchange，提问作者Zelly123