如果一路是风平浪静，那么旅途是单调无味的。
在技术领域，尤其是软件开发行业，技术问题或bug常被戏称为坑。技术坑让人痴迷、抓狂、惊喜、沮丧、郁闷，但终究令我在痛并快乐中快速成长。
最近团队利用前后台分离开发一个项目，前端采用bootstrap + angular 1 + bower + grunt，后端采用spring boot。开发接近尾声，今天打算部署项目至客户的线上服务器，邀请客户一起参与内测。线上的环境为Cent OS 7.0 64位。在前端构建环境安装完毕之后，执行命令<code>grunt build</code>构建时，出现一个task warning：<code>Running "ngtemplates:dist" (ngtemplates) task killed</code>。后续的构建任务因这个warning而被终止。
看到这个warning事，自己脑海里一片空白。之前从未遇到过这样的问题，而且warning的信息给得太简短，根本找不到任何头绪。开始以为是任务<code>ngtemplates:dist" (ngtemplates)</code>的构建脚本有问题，但这个构建脚本在测试服务器上执行过成千上万次，并未出现过任何问题，所以可以初步排除脚本的原因。
那么可能是什么原因产生的呢？利用万能的网络搜索，希望马上找到该问题的解决办法。但在尝试了变换几次关键字之后，仍旧没有找到类似问题的解决办法，就连类似的问题都很少有人提及。到底是什么原因引起的呢？做技术的朋友，尤其熟悉linux环境以及擅长前端的伙伴们，可以马上花三分钟想想可能的原因在哪里。
沉思者以下内容强烈建议在思考三分钟之后阅读
三分钟，自己没有思考出任何结果来，仍然是一片空白。如果你也是此类人，那么不要惊恐，你不孤单。
stackoverflow截图如果不仔细看这个回答，你可能看不懂它在说什么。其实这位回答者在告诉大家，这个问题的发生可能是grunt-shell没有很好处理进程的退出事件。正因为没有退出事件（回调函数）没有正确被处理，所以无法看到更加详细的信息，可能就给一个很简单的提示。虽然这个帖子的问题与自己遇见的不同，但现象具有一定的关联性。
如果是未能正确处理进程的退出事件，那么是什么原因导致的呢？Linux系统一般以其稳定性著称，也就是说在大多数情况下，进程的退出事件可以被正确处理。在本地的开发环境，同样一份代码可以正确地被构建，所以代码不会存在问题。那么只有一种解释，系统环境的问题。
系统环境有什么问题呢？我们的服务器都是购买阿里的ECS，系统环境的配置及安全设置，我基本没有做过很大的修改，而且我们对阿里云平台的稳健性还是十分信任。会不会是服务本身的性能存在问题？自己脑海里突然蹦出这个想法。自己利用<code>free -l</code>查看了服务器的内存使用情况，不看不知道，一看吓一跳，服务的可用内存不到100MB。如果跑grunt的构建，那么是不是因为内存不够而出现未能正常退出，就直接被系统给kill。
为了验证这个有点疯狂的想法，自己停掉了正在运行的tomcat及spring root服务，然后进行构建，居然神奇地成功了！太不可能思议了，原来是内存搞的鬼。那么一切的解释就合情合理了：当执行<code>grunt build</code>时，grunt尝试运行某个任务但因内存过低，无法做swap，进程退出事件也无法被正常激发，仅给出了一个简洁的提示。
这坑确实令人有点摸不着头脑，没有相关问题信息的辅助，没有大胆假设小心求证的思考，是无法很快解决，甚至无法解决这个问题。
不知你猜对问题的原因了吗？欢迎留言说说你思考过程以及结果。
无戒写作训练营三期第十七天。学号77。