next »

[Huy H.]

In our current direct SSH connection, whenever we exit the "launcher" application, all child applications that was launched by the launcher exits.  Is there a way to mimic this behavior with a GAS connection?

We have tried using the gasadmin session command:

Code

    LET fglasdir = FGL_GETENV("FGLASDIR")
    LET xcf_file = FGL_GETENV("VDXFILES"), "/etc/wc_rms_main.xcf"
    LET dispatcher = "fastcgidispatch"
    LET kill_session_cmd = SFMT("%1/bin/gasadmin session -k %2 -f %3 -d %4",
                               fglasdir, session_id, xcf_file, dispatcher)
 
    RUN kill_session_cmd RETURNING run_status
 

While this works in ending all applications that was spawned by that session, the front-end response is not very desirable:
In both GDC and GBC, we would get the attached user-unfriendly error messages.

[Laurent G.]

Hi Huy,

The default popups might not be friendly but what you see is an expected message since you are killing the connections via gasadmin on the server side without the GDC knowing.

The GAS feature you might want to consider is autologout which will prompt the user to stay connected and then after further inactivity will close the main/starter app as well as the child applications:
 
https://4js.com/online_documentation/fjs-gas-manual-html/#gas-topics/c_gas_asref_AUTO_LOGOUT.html

Can you elaborate on the launcher app with SSH. You'll start child apps via RUN WITHOUT WAITING ? Do you keep track of all pids in a script and do some 'cleanup' before exiting the main BDL program ?

Best

Laurent

[Huy H.]

Our direct SSH setup is pretty simple.  We just invoke a shell script that setups the environment and run the main launcher program.

@FGL;exec /usr/local/bin/VDXinvoke.sh; exit;

All the child programs that's launched from the launcher program RUN WITHOUT WITHOUT waiting.  As soon as the launcher application exits, the shell script completes execution and the shell session ends, killing all child programs running via that session.

I don't think the AUTO_LOGOUT will work for us because this is not a timeout issue.  The user actually wants to end all process and exit.  At the moment, they would have to close each program individually when it's a GAS connection.

We are exploring custom process management options, but given that FGL_GETPID() is the only available method to return the current process id, it's somewhat challenging -- we cannot get the pid or the parent process, or get the pid of the child process that was just launched.

[Candy M.]

Hi Huy,
     In our application, we actually want the user to close out all programs that were launched so there will be an orderly exit and we can record a logout record.
     When the user tries to close the launcher application, the application will check to see if there are any child processes still running and display them to the user.   In order to do that, we use the ps command in linux and then parse the output.
     So you could possibly do a ps command before exiting and then kill the child processes.
     We use a ps command like this:

Code

 LET ps_command = "ps he --user ",user_name.trimRight()," -o args"
 

        where user_name is the user's name.
       Now we currently use impersonation when running GAS for the applications so the applications are not currently being run as one generic user and are run as the actual linux user.
       We may in the future change so that all applications are run as one user.   If we do that, we may pass the user name to all apps so the user name could show in the ps command.
     
Candy

[Laurent G.]

Candy,

The difference is that you are running your application in MDI mode, aren't you?

Laurent

[Candy M.]

Laurent,
      We are not running our application MDI mode.  I'm not sure I know how to do that.  :-)
Candy

[Laurent G.]

Sorry about the confusion Candy,

I meant all subprograms are all running within the same browser tab or Windows container.

Laurent

[Candy M.]

Laurent,
    If the user is running our application in GAS/GBC, we use this style on the window that is opened at the MENU launcher statement (we build our menu dynamically):

Code

<Style name="Window.mtmain_tree_gbc">
     <StyleAttribute name="windowType" value="normal" />
     <StyleAttribute name="ignoreMinimizeSetting" value="yes" />
     <StyleAttribute name="startMenuPosition" value="tree" />
     <StyleAttribute name="startMenuSize" value="large" />
     <StyleAttribute name="actionPanelPosition" value="none" />
     <StyleAttribute name="ringMenuPosition" value="none" />
     <StyleAttribute name="toolBarPosition" value="none" />
     <StyleAttribute name="errorMessagePosition" value="popup" />
     <StyleAttribute name="tabbedContainer" value="yes" />
  </Style>
 

      So the effect is that each 42r that is launched, it shows as a separate folder tab.   Then we replace the emptytabbed.png with our own splash screen.

Candy

[Reuben B.]

In our current direct SSH connection, whenever we exit the "launcher" application, all child applications that was launched by the launcher exits.  Is there a way to mimic this behavior with a GAS connection?

First of all, I wouldn't describe that as the expected behaviour.  My expectation is that if you have used RUN WITHOUT WAITING then the child applications would remain running after the launcher exits, and am thinking that maybe something is missing in the SSH or GDC shortcut config

So I'd first make sure that you are not trying to reproduce behaviour that is incorrect and not desired.

If the behaviour is desired, and it might well be in the security conscious environment you operate in , I'd draw a diagram of the processes running,
GDC+SSH:  fglrun gdc.exe
GDC+GAS: fglrun, *dispatch, uaproxy, gdc.exe
GBC+GAS: fglrun, *dispatch, uaproxy, browser.exe+gbc.js

and note that your gasadmin technique is killing the uaproxy processes which is then bubbling up to the fglrun, gdc.exe, browser.exe+gbc.js, and what you are seeing in UI is the response if communication is lost with a process that should be running

I would look at a technique whereby the fglrun process is  shutdown in an orderly fashion.

I have two thoughts as to how to construct

1. If you look at fglWrt -a info users, output you should see that the processes for that session_id  the application launcher and the programs launched) are grouped together so I think you can use that info to get the process id's you need.
2. Secondly, if you look at OPTIONS ON TERMINATE SIGNAL http://4js.com/online_documentation/fjs-fgl-manual-html/#fgl-topics/c_fgl_programs_009.html you can execute code when a terminate signal (kill -15) is received.

So I am thinking, parse the fglWrt -a info users output to get the process Ids, kill -15 on those process ID, and use OPTIONS ON TERMINATE SIGNAL to have these programs exit in a tidy manner, and then the front-end will be as if the user exited the program normally.

I'm not comfortable suggesting this as I think you are trying to mimic some behaviour that is not correct.

Reuben

[Sisavanh S.]

Hi,

Discussing with the development team, I have filed request:
GAS-3615: Ability to gracefully close a session using gasadmin

With GAS, the connection is not persistent.
The front end is aware of the end of the session in the next coming request.
We might have a solution to gracefully manage this.

Best regards,
Sisa.

[Reuben B.]

Hi,

Discussing with the development team, I have filed request:
GAS-3615: Ability to gracefully close a session using gasadmin

With GAS, the connection is not persistent.
The front end is aware of the end of the session in the next coming request.
We might have a solution to gracefully manage this.

Best regards,
Sisa.

One question that might need to be considered is the order in which programs that are managed by the session are stopped, particular if there are any that have been launched RUN RETURNING.  If the order is indeterminate (as is the case with AUTO_LOGOUT), then if you have a parent launching a child using RUN RETURNING, you face the possibility that half the time the parent is stopped before the child and no processing occurs after the RUN RETURNING in the parent, and the other half the time the child is stopped first and some of the processing occurs after the RUN RETURNING in the parent. 

Reuben