问题：
linux环境下，
/fileserve目录的所属组为transfer，有写权限;
现在有java程序运行用户runapp，所属组为appgrp，附属组为transfer；
现发现linux服务器中，直接用runapp用户登录，可/fileserve目录下创建文件，但是由runapp创建的java进程却没有写权限。
注：
问题前后java进程启动了两次:
1. 第一次由由自动化代理程序调起，自动化进程名：susagent
2. 第二次由linux服务器`runapp`手工执行脚本调起的
现场：
自动化进程启动时间：15号；
runapp用户附属组transfer是在17号添加的，之后没有重启过代理susagent进程；
18号发现问题，手工重启java进程后，发现java程序运行用户runapp对/fileserve目录又拥有了写权限。
排查问题：
为什么手工重启java进程后又可以？
分析java进程前后差异，发现没有权限的java进程是由自动化代理进程
susagent调起的，而且有权限java进程是linux服务器runapp手工执行脚本重启的。
定位问题：为什么自动化代理调起的进程无权？真的狗啊
用的
runapp调起自动化代理进程，同时调起通过自动化调起的java进程运行用户也是runapp，所属组权限也没问题，怎么这么狗偏偏自动化代理调起的进程没权限？
最后发现自动化代理进程是15号调起的，而runapp用户附属组transfer是在17号添加的。
最后在无数次的调式中发现，自动化进程启动之后，对进程所属用户添加附加组，发现所属用户并没有附加组的权限，重启之后即可。
结论：
`susagent`进程调起的`java`进程（运行用户为`runapp`），在linux服务器中直接对`runapp`
添加附加组，用自动化部署平台不断重启`java`进程，`runapp`用户所添加的附属组并不会生效，因为
自动化`java`进程是由`susagent`进程调起的，而`susagent`在`runapp`添加附加组后一直没有重启
过，所以`susagent`进程的运行用户`runapp`并不会拥有附属组权限，自然而然由`susagent`进程调起
的`java`也不会继承附属组权限
