吐槽一下 windows 的终端的一个天坑

[vituralfuture]

一个 django 开发的后端，因为是学校里的学长组织的项目，所以给了一个他们实验室里的一台 windows 作为服务器，平时远程上去用。最近有一个接口account/check经常卡死，具体情况就是

• 不断开连接，但一直没有响应
• 浏览器可能有超时自动断开，curl命令不会断开，所以会一直卡死

其他接口都正常

我上服务器上排查了一下，发现了一个天坑 cmd 窗口在选中模式下，account/check会卡死，其他接口正常但是终端没有输出（ django 处于调试或者开发模式，每请求一次都打印在终端）

去网上查了一下，找到了这个 https://stackoverflow.com/questions/33883530/why-is-my-command-prompt-freezing-on-windows-10

虽然不知道为什么只有account/check会出现这个问题，不过可以确定这个选择模式真是一个大聪明

网上找到的解决方案是：关闭 Quick Edit Mode

但我觉得这还是不太方便。如果这种大聪明功能一多，岂不是拿到一台新的 windows 机器还要设置一堆东西？我觉得可能是使用终端的方式错了，v 友们有没有遇到这个问题？都是怎么解决的？

[MrKrabs]

就是鼠标不小心点一下就暂停这么弱智的哦

[siweipancc]

设计出来就不是给你这么用的……

[Chancel]

@chackchackGO 看程序类型了，nohup 的写法不是太友好

比如我需要记录程序的输出，那么 nohup 的写法就复杂了一点，如果希望切割日志，那么`nohup`就会很复杂了

就我的使用经验而言，写一个`supervisor`的配置单是最简便的

如果程序很简单，只需单纯的需要在后台跑，那我觉得`tmux`也比`nohup`要强

[chackchackGO]

@Chancel 我这个新手一直就是用的 tmux. nohup 确实感觉相比之下很不方便和难记语法.
但是看到很多文章和老手用 nohup, 所以有些自我怀疑...

[lsk569937453]

被楼上喷的我都不敢在生产环境用 nohup 了。

例：比如我需要记录程序的输出，那么 nohup 的写法就复杂了一点，如果希望切割日志，那么`nohup`就会很复杂了
答：有没有可能根本不会在代码里写 System.out.println 或将日志输出到 stdout ，而是直接将日志写到文件，用日志工具自动切割。

[sanzrolee]

建议你用 Supervisor 跑 Python 服务，用 nohup ，终端就是会卡住的，我通常都是关闭窗口就算了。用 supervisor 就不会出现这个问题，还能监测服务的运行状况。

[adoal]

@lsk569937453 对的，比如用 logrotate 做切割，这玩意不但可以配置各种切割规则，而且还可以指定切割前执行任意外部操作做预处理、切割后执行任意外部工作做善后。最好是你的程序支持收到 HUP 信号或者别的触发条件时 reopen 日志文件，这样切割的事完全不用放在自己的程序中处理，只要闷头写就行了。

[Chancel]

@lsk569937453 首先我没喷`nohup`，强调了是个人体验，`nohup`存在即合理

其次，在代码中配置输出到文件是入门编程的常识，比`nohup`还简单多了，python 的`logging`、golang 的`logrus`，C#的`log4net`等等，一个了解`systemd`的人写代码用`print`是不可思议的

但日志库跟`nohup`有关系？因为有这些库做日志切割，所以`nohup`配置日志不方便就不存在了？

`nohup`就比`systemd`和`supervisor`更好了，更遑论`nohup`不支持一键重启，自动重启，运行用户配置，系统环境单独定义等诸多功能，这些只有`systemd`和`supervisor`这类守护进程支持

开发和运维工作是分开的情况下，多个项目组各自定义自己的文件输出在各自的目录下有着各自的切割规则，运维更合适收集程序的 CLI 输出并按照实际服务器资源情况进行切割是更合理的

我的个人技术体验路线是：screen-nohup-supervisord-systemd

拧螺丝只要口对的上都行，但使得顺不顺手是另外一回事