【 使用环境 】测试环境, centos7.5.1804
【 OB or 其他组件 】oblogproxy
【 使用版本 】 v2.0.2_BP1
【问题描述】安装 oblogproxy rpm 包, start 后整个操作系统的 /usr/bin目录被删除,系统无法使用.复现步骤:
好的.你们可以本地找台机器测试下.
run.sh 不会操作 /usr/bin 目录，你说这个现象应该不是 logproxy 引起的
没有碰到过这样的问题
你试了没有?步骤都给你了,你不会自己试试?
要不给你录个像?还是你现场看我操作?
我上面的回复是想告诉你，logproxy 程序本身和启动脚本都不会修改 /usr/bin 目录，我们在内部本地部署和运行过很多次，没有遇到过这种问题。
logproxy 服务目前是不需要管理员权限的，所以你可以试试用普通用户启动，这样是没有删除系统文件的风险的。
我还发现,如果 rpm 安装时不指定目录, 就没有问题,只要指定了其它目录就会出现这个现象.
如果你是用 root 用户解压的，需要把工作目录的 owner 转成启动用户。另外，不是说不能用 root 用户部署，我这么提议只是给你提供一个排查的方法。
我试试不难，但是我的时间并不是很充裕，因为知道部署脚本里涉及哪些操作，所以我给出了上面的结论，如果你不认同我尊重你的想法，但是现在这种指责我并不接受。
你可以再试试修改一下 conf.json 里的 oblogreader_path、bin_path、oblogreader_obcdc_ce_path_template 这些参数，自定义解压目录时这些都要跟着调整的。另外 config_sys 时的用户名不能带 @sys ，一起改一下。
整个测下来不超过5分钟.
所以你为什么这么纠结于我到底有没有当场测试过呢？难道重点不该是定位和解决问题吗？
我前边跟你讲过了，我们内部本地部署和运行过很多次，这里的运行包括默认安装和指定目录安装、CDC 模式和 Binlog 模式，这些都测过，启动脚本我也确认过没有可疑的删除操作，我说一个跟 logproxy 无关的结论有什么问题吗？
我上面的回复不是在帮你定位问题吗，我也不是说随时都能有时间、有资源来配合你搞这搞那，社区支持本身就是这样，都是抽时间搞的，我也有本职工作啊，怎么不按你说的现操作一遍就是我不负责了？
你昨天第一次回复都在空谈啊,并不是实际解决问题,完全就是"我们测了没问题",再说文档也没写的很细致啊,我指定目录安装,就算没有改 conf.json 的路径, 它就可以把我的系统目录删掉吗?这个你们不该查查吗?
我不明白为什么你每次回复都带这么多情绪，我第一次回复同样是在排除可疑点。如果你只有正文描述的操作，我们内部确实进行过同样的操作，没有出现过这种问题，所以我在不确定你的具体操作是不是只有这些的情况下，排除了 run.sh 脚本引起问题的可能性，这怎么就成空谈了？
后边提出换用户，如果普通用户启动依然被删，因为普通用户不可能删除系统目录，是不是就可以得出不是启动 logproxy 引起的？这不是又排除了一些可能？
看了strace的日志调用，没有涉及到rm 的系统调用，且日志表明oblogproxy是启动的
说明run.sh的脚本应该是没什么问题的；
上面的步骤确实能稳定复现/usr/bin被破坏的问题，这个建议社区同学需要跟进一下；从日志上看，理解是oblogproxy二进制里面的逻辑在这样的配置方式下，存在破坏系统的bug？ 变更运行用户是一个绕过方案，不过对破坏系统对社区用户看上去确认存在重大风险 
这个问题我们正在跟进，研发的老师也确实比较忙，感谢反馈，有进展会尽快回复您。
