sqle异常退出后重新拉起，会有多个插件进程存在

[iwanghc]

版本信息（Version）

SQLE：main ee 815ad05f8
DMS：main ee a8a69c2
UI：main ee 36559656

问题描述（Describe）

sqle进程异常终止或强制退出后（如kill -9），sqle会自动重新拉起，此时会重新启动插件进程，但是老的插件进程不会被关闭，消耗资源。

如何复现（To Reproduce）

1、启动sqle，此时有pg的插件进程正在运行

2、kill -9 强制退出sqle

3、待sqle重新拉起后发现pg有两个进程存在

实现方案

方案一：【sqle启动时kill插件进程】sqle启动插件时，通过插件名称判断当前插件是否已有进程存在，若有则kill
方案二：【由sqle管理插件进程，sqle创建插件进程pid文件】当sqle启动插件时，判断插件pid文件内容，若不为空则发送退出进程信号。
方案三：【由插件自身管理进程，插件创建自身进程pid文件】当插件启动时判断对应pid文件内容，若不为空则kill进程。

最终方案

方案二，

方案一
优点：操作进程比较直接，省去文件操作，速度较快。
缺点：风险高，使用插件名称查进程，存在误杀进程的可能
方案二：
优点：仅操作文件记录的pid，风险和影响相对较小，又因插件由sqle启动，所以管理其进程也符合当前逻辑。
缺点：需要修改sqle启动插件逻辑，若杀残留进程panic，会导致sqle启动失败。
方案三：
优点：不需要修改sqle启动逻辑，对sqle影响小。
缺点：影响范围大，当前插件数量较多，需每个都修改，还涉及到不同语言开发的插件，修改成本较高

选择方案二原因：
综合来看方案二影响小，风险小，后期扩展性也较高，可实现统一管理插件进程（假设后期有个插件管理功能，控制插件的启停），就缺点来讲，即使插件自身panic，sqle也会启动失败，所以方案二更适合。

变更影响面

若插件pid文件手动删除，sqle异常终止重新拉起后插件会残留，因为sqle会读取插件文件记录的pid kill进程。
插件进程手动kill，sqle重新拉起pid文件记录是最新的插件pid。
sqle正常退出，插件进程随之退出，插件pid文件也随sqle停止而删除。

[iwanghc]

提升插件pid文件夹的权限，修复创建pid文件时权限不足问题
问题原因：
插件pid文件夹为0644，没有执行权限，导致无法open该文件夹创建pid文件
解决：提升pid文件夹权限至0755

[BugsGuru]

复现

版本：
DMS: main-ee 9025ba5e3f
SQLE: main-ee 6cee525631

1. 正常启动sqle
2. 强制退出sqled进程
3. systemd自动重启sqled
4. 每种（DB2、PG）插件存在两个进程，复现成功
   
5. systemctl restart sqled 时，插件也会重启（旧进程正常退出，新sqle启动新插件进程）
   
6. 再次强退sqled进程，会再多出一组插件
   

验证

版本：

DMS: main-ee d67bfc170a
SQLE: main-ee 94528c99c2

centos7环境

1. 正常启动sqle，生成插件pid文件
   
2. 强制退出sqled进程
3. systemd自动重启sqled
4. 残留插件进程被清，插件pid文件更新
   
5. systemctl restart sqled 时，插件pid文件更新
   
   符合预期，验证通过

Ubuntu18环境

1. 正常启动sqle，生成插件pid文件（java插件记录的是sh启动脚本pid）
   
2. 强制退出sqled进程，pid文件还在，插件进程还在
   
3. 重启sqled，旧java插件残留，仅清理了其启动脚本进程，其他插件正常
   
   不符合预期，已新增issue处理该问题，故本issue验证通过