树莓派Java进程无日志莫名退出，如何配置JVM参数完成事后故障分析

• 你当前配置的启动参数已经修正了之前找不到hs_err文件的核心问题：通过绝对路径显式指定-XX:ErrorFile，从根本上避免了工作目录不确定导致的日志写入失败、路径找不到的问题。
• 配置生效前提：确保-XX:ErrorFile指定的路径对运行Java进程的用户有读写权限，避免因为权限不足导致日志无法生成。
• -XX:OnError的最优配置注意事项：
  • 该参数仅会在JVM遭遇原生级崩溃（如JVM自身bug、JNI层内存越界、直接内存访问越界）时触发，程序正常退出、被内核强杀、业务代码抛异常退出的场景下不会执行对应脚本。
  • 触发时的JVM已经处于不可靠状态，脚本内所有操作必须使用绝对路径，不能依赖交互式shell的环境变量，同时要给脚本赋予可执行权限。
  • 脚本不能只做简单的通知逻辑，要兜底保存现场关键信息：比如当前系统内存占用、最近的内核日志、崩溃时的系统状态，避免关键信息丢失。
  • 简单的脚本参考：

    #!/bin/bash
    CRASH_SAVE_DIR=/home/pi/Server/crash
    mkdir -p $CRASH_SAVE_DIR
    SAVE_FILE=$CRASH_SAVE_DIR/crash_info_$(date +%Y%m%d%H%M%S).log
    free -m > $SAVE_FILE
    echo "---" >> $SAVE_FILE
    dmesg | tail -100 >> $SAVE_FILE
    

• 为什么kill -9无法触发验证逻辑：SIGKILL（信号9）是不可被用户态程序捕获的信号，内核会直接回收进程资源，完全不给JVM执行崩溃日志生成、钩子脚本的机会，自然达不到验证效果。
• 可触发原生崩溃流程的正确模拟方式：
  1. 启动Java程序后，通过ps -ef | grep java找到对应进程的PID
  2. 执行kill -11 <PID>：该信号是段错误（SIGSEGV）信号，属于JVM注册了信号处理函数的异常信号，会完全模拟真实原生崩溃的流程，正常触发hs_err文件生成、执行-XX:OnError指定的脚本。
• 验证检查项：模拟触发后，检查/home/pi/Server/路径下是否生成对应的hs_err_pid<PID>.log文件，指定的OnError脚本是否被正常执行、是否生成了对应的崩溃信息文件，两项都正常则说明配置生效。

你遇到的程序运行数小时/数天后消失、无业务报错的场景，大概率不属于JVM原生崩溃，可按以下顺序排查：

• 优先排查系统级主动杀进程的场景：
  • 树莓派内存资源有限，OOM Killer触发概率极高。执行dmesg | grep -i "out of memory\|killed process"，如果找到对应Java进程的被杀记录，说明是系统内存不足时内核主动回收了进程资源，这种场景下JVM完全没有生成日志的机会。
  • 排查之前裸用&启动的问题：SSH断开连接时，系统会给该会话下的所有后台进程发送SIGHUP信号，如果没有通过nohup、disown或者systemd服务托管处理这个信号，进程会直接静默退出，不会留下任何日志。
• 优化启动方式建议：
  • 后续启动不要用裸&挂后台，建议改成nohup java [你的JVM参数] -jar /home/pi/Server/myjavatool-0.1.2.jar > /home/pi/Server/stdout.log 2>&1 &，将JVM所有标准输出、错误输出全部落地到文件，就算进程异常退出，也能看到最后输出的内容定位线索。
  • 如果追求长期运行稳定性，建议将程序做成systemd服务托管，自动处理进程的信号响应、开机启动、异常重启逻辑。

内容的提问来源于stack exchange，提问作者yuppie