Vaibhav Parab (Customer) asked a question.
OS-COMMAND to execute _progres on PASOE leaves 'defunct' unix sub-processes resulting in SYSTEM ERROR: MAXSUBP: too many subprocesses. (357)
We have a PASOE apsv WEBAPP which executes OS-COMMAND to initiate another _progres session in batch mode. The OS-COMMAND is run with NO-WAIT. The PASOE sessions are connected in SESSION-MANAGED mode. Below is how the OS-COMMAND looks like which run on the PASOE. vDLCPath holds the absolute path to _progres.
- OS-COMMAND NO-WAIT VALUE (vDLCPath + " " + "-baseADE " + PROPATH + " " + vDataBaseConnection + " -p runner.p -b -param " + vCommandLine).
When investigating all sub-processes associated with the PASOE, it shows a number of 'defunct' entries. These seem to exhaust the quota of sub-processes and any future attempt to run the above command by a later session/connection fails with the below error.
SYSTEM ERROR: MAXSUBP: too many subprocesses. (357)
How to ensure that the sub-processes are completed and removed?
Plain Text pasoe-pasoe_app-12287_0260402_1104AM
Not sure about the defunct processes. But generally, the usage of OS-COMMAND and INPUT THROUGH on PASOE on Linux can be problematic.
https://community.progress.com/s/article/pasoe-server-running-os-command-or-unix-statements-runs-very-slowly
As you're already using an AppServer, have you considered using asynchronous AppServer requests instead?
@Mike Fechner (Consultingwerk) , I have previously gone through the same link that you shared and what interests me is the idea of re-organizing the number of Agents-vs-Sessions. Unix's max sub-process threshold seems to be applicable at multiple levels (I am NOT a UNIX expert!) - Kernal, User, Parent Process. I am thinking of trying out the suggestion of reducing the Sessions per Agent and increasing the Agents. If the threshold I am hitting is at the Parent Process level, this workaround should provide a relief.
@James Palmer (Vertu Motors PLC) can you please elaborate on why QUIT. should make any difference here? We're still discussing _progres -b launched througth OS-COMMAND here. QUIT _should_ not make any difference.
@James Palmer (Vertu Motors PLC) - a PASOE restart cleared up the defunct processes. Does PASOE have a counterpart to 'trim' in Classic AppServers? If so, I can give it a try.
Nonetheless, this is just a work around.
The runner.p does not end with a QUIT. But I have doubts same as @Mike Fechner (Consultingwerk) . I will try it though.
The PASOE equivalent is named "refresh agents". If you're in 12.2 and up, see https://docs.progress.com/bundle/pas-for-openedge-management-122/page/Refresh-agents-in-an-ABL-application.html for more.
Note that this does NOT restart the agent process(es) , only the ABL sessions contained in them. So it is not 100% equivalent with the classic trim operation.
Apologies regarding the QUIT - I misread something.
I tried the QUIT in runner.p. Didn't help.
@Peter Judge (Consultingwerk) Tried "refresh agents", but that does not flush the defunct processes. But stopping MS-Agent did. Not sure how this works.
At this point, Progress Tech Support will be your best bet.
I will have to consider async AS request if I do not find a solution to the defunct processes problem. I haven't noticed any performance issues with the OS-COMMAND calls on PASOE until this recent discovery.