记一次由于不当的启动服务方式导致线上报错的排查经历

项目背景：中科方德 / Springboot / JDK1.8 / 达梦数据库7.0

具体问题：登录系统以后任意操作都显示登录过期，请重新登录，再次登录依旧过期，无法做任何操作

排查过程：

看F12登录接口是返回了登陆成功的token，但是任意操作调的接口都直接返回登录过期并且清除掉token导致需要重新登录。

经过查看代码后发现逻辑是登陆时往redis写入一个登录的时间，然后每次操作时根据当前时间作对比，如果小于超时时间则刷新，大于超时时间则提示超时。

测试后发现线上环境无法正常刷新上次操作时间，第一次登陆以后时间就无法修改，导致只要在第一次登陆+超时时长以后的所有操作都认为超时。

经确认以后代码逻辑没有问题，基本确定是redis的原因。

找到对应的key以后手动在redis中修改值报错 MISCONF Redis is configured to save RDB snapshots，百度以后是因为redis持久化失败以后就无法继续修改内存中的值了，可以通过将 stop-writes-on-bgsave-error 设置为 no 来让redis即使持久化失败也可以修改内存的值，修改以后项目恢复正常。

但是这毕竟只是治标不治本，还需要找到redis持久化失败的原因（当然我也不知道为啥这个要持久化，完全没有必要）。

查看以后发现redis持久化所在盘被nohup.out占满了，而服务器上所有的应用系统日志全部输出到了这个nohup.out中。

然而应用系统都放在另一个大磁盘中，日志也不应该输出在这里。

之后根据之前部署人员留下的文档发现，所有应用系统启动的命令都是在/root下执行的，也就导致nohup全部输出到了/root下，导致磁盘爆满。

后续将日志清理掉，所有应用系统编写脚本放在应用目录下并重启，nohup输出到正确位置以后系统恢复正常。

总结：真几把坑