Linux用户权限

问题：

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`也不会继承附属组权限