time="2017-01-19T18:22:41.368392532+08:00"level=error msg="Handler for POST /v1.23/containers/338016c68da6/stopreturned error: No such container:
338016c68da6"
是Docker 1.9以来就有的问题，1.12.3修复了。参考https://github.com/docker/docker/ issues/24211
比如Github上有人回复：
“I have been update my docker from 1.11.2 to 1.12.3, This issue is fixed.
BTW, this error message can be ignored, it should really just be a warning.”
但这里所说的都只是v1.12.2版本就能修复的问题，我们升级Docker版本后发现死机依旧。
于是，我们接着通过各种Google确认了很多与我们存在相同故障现象的问题，初步确认故障与D
ocker的相关性：
又根据以下官方issue初步确认Docker版本与系统内核版本不兼容可引发宕机的关联性：
接着，通过官方的changelog和issue确认宿主所使用Docker版本与系统内核版本不兼容问题：
出于尝试心理，我们把Docker版本升级到1.12.2后，未出意外仍出现死机。
2.使用Linux bridge方式改造宿主网卡可能触发bug
找了那台宿主跑服务一周就会死机的宿主，停止运行Docker，只改造网络，稳定跑了一周未发现异常。
3.使用pipework给Docker容器配置IP可能触发bug
由于给容器分配IP时我们采用了开源的pipework脚本，因此怀疑pipework的工作原理存在bug，所以尝试不使用pipework分配IP地址，发现宿主仍出现死机。
于是初步排查陷入困境，眼看着宿主每月至少死机一次，非常郁闷。
因为还有线上业务在跑，所以没有贸然升级所有宿主内核，而是期望能通过升级Docker或者其它热更新的方式修复问题。但是不断的尝试并没有带来理想中的效果。
直到有一天，在跟一位对Linux内核颇有研究的老司机聊起这个问题时，他三下五除二，Google到了几篇文章，然后提醒我们如果是这个 bug，那是在 Linux 3.18 内核才能修复的。
参考：
-
https://lists.gt.net/linux/kernel/2256803
-
https://lkml.org/lkml/2014/2/15/217
-
https://github.com/docker/docker/issues/21081
-
https://github.com/torvalds/linux/commit/eeb61e53ea19be0c4015b00b2e8b3b2185436f2b
从sched: Fix race between task_group and sched_task_group的解析来看，就是parent 进程改变了它的task_group，还没调用cgroup_post_fork()去同步给child，然后child还去访问原来的cgroup就会null。
不过这个问题发生在比较低版本的Docker，基本是Docker 1.9以下，而我们用的是Docker1.11.1/1.12.1。所以尽管报错现象比较相似，但我们还是没有100%把握。
但是，这个提醒却给我们打开了思路：去看内核代码，实在不行就下掉所有业务，然后全部升级操作系统内核，保持一个月观察期。
于是，我们开始啃Linux内核代码之路。先查看操作系统本地是否有源码，没有的话需要去Linux kernel官方网站搜索。
```
apt-cache search linux-image-3.16.0-4-amd64
apt-get source linux-image-3.16.0-4-amd64
```
下载了源码包后，根据报错syslog的内容进行关键字匹配，发现了以下内容。由于我们的机器是x86_64架构，所以那些avr32/m32r之类的可以跳过不看。结果看下来，完全没有可用信息。
/kernel/linux-3.16.39#grep -nri "unable to handle kernel NULL pointer dereference" *
arch/tile/mm/fault.c:530: pr_alert("Unable to handlekernel NULL pointer dereference\n");
arch/sparc/kernel/unaligned_32.c:221: printk(KERN_ALERT "Unable to handle kernel NULL pointerdereference in mna handler");
arch/sparc/mm/fault_32.c:44: "Unable to handle kernel NULL pointer dereference\n");
arch/m68k/mm/fault.c:47: pr_alert("Unable tohandle kernel NULL pointer dereference");
arch/ia64/mm/fault.c:292: printk(KERN_ALERT "Unable tohandle kernel NULL pointer dereference (address %016lx)\n", address);
debian/patches/bugfix/all/mpi-fix-null-ptr-dereference-in-mpi_powm-ver-3.patch:20:BUG:unable to handle kernel NULL pointer dereference at (null)
最后，我们还是下线了所有业务，将操作系统内核和Docker版本全部升级到最新版。这个过程有些艰难，当初推广这个系统时拉的广告历历在目，现在下线业务，回炉重造，挺考验勇气和决心的。
