問題：
linux環(huán)境下，
/fileserve目錄的所屬組為transfer官觅，有寫權(quán)限;
現(xiàn)在有java程序運行用戶runapp件缸，所屬組為appgrp房蝉，附屬組為transfer公荧；
現(xiàn)發(fā)現(xiàn)linux服務(wù)器中带射，直接用runapp用戶登錄，可/fileserve目錄下創(chuàng)建文件循狰，但是由runapp創(chuàng)建的java進(jìn)程卻沒有寫權(quán)限窟社。
注：
問題前后java進(jìn)程啟動了兩次:
1. 第一次由由自動化代理程序調(diào)起，自動化進(jìn)程名：susagent
2. 第二次由linux服務(wù)器`runapp`手工執(zhí)行腳本調(diào)起的
現(xiàn)場：
自動化進(jìn)程啟動時間：15號绪钥；
runapp用戶附屬組transfer是在17號添加的灿里，之后沒有重啟過代理susagent進(jìn)程；
18號發(fā)現(xiàn)問題程腹，手工重啟java進(jìn)程后匣吊，發(fā)現(xiàn)java程序運行用戶runapp對/fileserve目錄又擁有了寫權(quán)限。
排查問題：
為什么手工重啟java進(jìn)程后又可以寸潦？
分析java進(jìn)程前后差異色鸳，發(fā)現(xiàn)沒有權(quán)限的java進(jìn)程是由自動化代理進(jìn)程
susagent調(diào)起的，而且有權(quán)限java進(jìn)程是linux服務(wù)器runapp手工執(zhí)行腳本重啟的甸祭。
定位問題：為什么自動化代理調(diào)起的進(jìn)程無權(quán)缕碎？真的狗啊
用的
runapp調(diào)起自動化代理進(jìn)程褥影，同時調(diào)起通過自動化調(diào)起的java進(jìn)程運行用戶也是runapp池户，所屬組權(quán)限也沒問題，怎么這么狗偏偏自動化代理調(diào)起的進(jìn)程沒權(quán)限凡怎？
最后發(fā)現(xiàn)自動化代理進(jìn)程是15號調(diào)起的校焦，而runapp用戶附屬組transfer是在17號添加的。
最后在無數(shù)次的調(diào)式中發(fā)現(xiàn)统倒，自動化進(jìn)程啟動之后寨典，對進(jìn)程所屬用戶添加附加組，發(fā)現(xiàn)所屬用戶并沒有附加組的權(quán)限房匆，重啟之后即可耸成。
結(jié)論：
`susagent`進(jìn)程調(diào)起的`java`進(jìn)程（運行用戶為`runapp`），在linux服務(wù)器中直接對`runapp`
添加附加組浴鸿，用自動化部署平臺不斷重啟`java`進(jìn)程井氢，`runapp`用戶所添加的附屬組并不會生效，因為
自動化`java`進(jìn)程是由`susagent`進(jìn)程調(diào)起的岳链，而`susagent`在`runapp`添加附加組后一直沒有重啟
過花竞，所以`susagent`進(jìn)程的運行用戶`runapp`并不會擁有附屬組權(quán)限，自然而然由`susagent`進(jìn)程調(diào)起
的`java`也不會繼承附屬組權(quán)限
