背景：之前就有一个在我账户名下的问题程序，但是并不是我启动的，绝对不是我启动的。但是找不到原因就莫名的背起了锅。然后默默修改了密码（其实然并卵，下面详聊原理），该机器管理员把我踢出了root组(因为没啥程序在上面)

起因：今日突然发现一个进程的cpu占用率一直处于100%+ 居高不下，同时还发现进程启动用户是我的名字，极其尴尬。

经过：但是我并没有启动过这个程序，因为我知道我自己开的程序，就两三个，而且都是轻量级的，不可能暂用这么大的cpu资源。

于是就开始查找问题所在，但是能力有限，只能依靠背后东日大佬。

于是乎大佬开始操作。
htop 查看进程PID，已经对应的命令

启动命令是celery 对应的后面还有cron可疑单词。PID 60372

celery是py的包，通过pip list | grep -i celery  查看 是否有该包，没有发现

通过 apt list --installed | grep -i celery 查看 apt是否有该包，没有发现

crontab -l 看看定时有没有异常的东西，没有发现。

ps aux |grep celery  看看有没有celery的程序启动，发现有几个程序。 这里算是发现了有用的信息。这个时候就比较尴尬了，没有这个包但是怎么启动的。带着疑问，继续探究。

怀疑某个包依赖这个celery，去py的包区域查找

cd  /.local/lib/python2.7/site-packages  

which celery   没有发现

which celeryd  没有发现

celery   执行没有反应

celery --help  仍然没有反应

find -iname "*celery*"   让然没有查到

cd /usr/lib/

find -iname "*celery*"    还是没有任何信息

cd /proc/7019  去PID 的工作目录

发现了  cwd 是sentry ,是sentry 启动的。其实到这个时候我东日大佬已经严重怀疑问题进程在docker里面，也确实如他所料

cat environ

pip version

看看环境里面确实是否有包的存在，没有发现

sudo docker ps  看看docker 

sudo docker exec -it ***_web_1 bash    进入第一个docker 看看，发现sentry 但是没有什么代码内容，也没有celery

更换下一个docker

sudo docker exec -it ****_worker_1 bash  进入第二个docker 看看，跟第一个一样。

sudo docker exec -it onpremise_cron_1 bash  第三个看名字十分可疑，cron 这个单词出现在之前的pid 程序命令中，

果然发现了可以的sentry和celery 到此处基本算是确定问题所在了。查看启动细节发现跟之前的一模一样。

通过询问该docker是其他同事启动，因该程序已经出现问题，就让他停下该docker，然后htop那个进程直接消失。

OK 现在很多人会有疑问，并不是我自己启动的，为什么docker启动程序为什么在我的名下。

大佬的正解是，查看一下你的uid

echo $UID   发现是999

大佬就给我说  docker非常喜欢用999这个uid

进入刚才的问题docker，发现sentry 就是999的uid。

linux 系统在监控的过程中是能够看到docker里的uid，由于跟自己的冲突，导致将该程序的被系统规划到我的名下了