Reduce shell overhead by calling configmgr directly

[1000TurquoisePogs]

As we move towards v3 and fixing bugs such that we could be configmgr-only and get rid of unnecessary use of shell, I notice that in our process tree, the launcher calls zwe which calls configmgr. If we know the env vars zwe will pass to configmgr, we can call configmgr directly to eliminate having it wrapped within a shell script.

The arrow in this screenshot is pointing to the shell process that could be cut out of the overhead.

The 4th element in the list can also be eliminated by enhancements in the JS scripting, elsewhere...

Below is a diff of unfinished work that should guide us to such a solution.

diff --git a/src/main.c b/src/main.c
index 1e46cca..af44652 100644
--- a/src/main.c
+++ b/src/main.c
@@ -460,7 +460,7 @@ static void set_shared_uss_env(ConfigManager *configmgr) {
     object = jsonAsObject(env);
   }

-  int maxRecords = 2;
+  int maxRecords = 5;

   for (char **env = environ; *env != 0; env++) {
     maxRecords++;
@@ -468,6 +468,11 @@ static void set_shared_uss_env(ConfigManager *configmgr) {

   int idx = 0;

+  //These are all properties that should not be changed by zowe.environments
+  arrayListAdd(list, "ZWE_CLI_PARAMETER_CONFIG");
+  arrayListAdd(list, "ZWE_CLI_PARAMETER_HA_INSTANCE");
+  arrayListAdd(list, "ZWE_zowe_runtimeDir");
+
   // _BPX_SHAREAS is set on component level
   arrayListAdd(list, "_BPX_SHAREAS");

@@ -480,6 +485,18 @@ static void set_shared_uss_env(ConfigManager *configmgr) {
   shared_uss_env = malloc(maxRecords * sizeof(char*));
   memset(shared_uss_env, 0, maxRecords * sizeof(char*));

+  
+  char configEnv[PATH_MAX+32];
+  char runtimeEnv[PATH_MAX+32];
+  char haEnv[256];
+  snprintf(configEnv, sizeof(configEnv), "ZWE_CLI_PARAMETER_CONFIG=%s", zl_context.config_path);
+  shared_uss_env[idx++] = configEnv;
+  snprintf(runtimeEnv, sizeof(runtimeEnv), "ZWE_zowe_runtimeDirectory=%s", zl_context.root_dir);
+  shared_uss_env[idx++] = runtimeEnv;
+  snprintf(haEnv, sizeof(haEnv), "ZWE_CLI_HA_INSTANCE=%s", zl_context.ha_instance_id);
+  shared_uss_env[idx++] = haEnv;  
+
+  
   if (object) {
     // Get all environment variables defined in zowe.yaml and put them in the output as they are
     for (JsonProperty *property = jsonObjectGetFirstProperty(object); property != NULL; property = jsonObjectGetNextProperty(property)) {
@@ -865,10 +882,15 @@ static const char **env_comp(zl_comp_t *comp) {
     env_records++;
   }

-  const char **env_comp = malloc((env_records + 2) * sizeof(char*));
+  const char **env_comp = malloc((env_records + 3) * sizeof(char*));

+  char componentEnv[256];
+  snprintf(componentEnv, sizeof(componentEnv), "ZWE_CLI_PARAMETER_COMPONENT=%s", comp->name);
+
+  
   int i = 0;
   env_comp[i++] = shareas;
+  env_comp[i++] = componentEnv;
   for (char **env = shared_uss_env; *env != 0 && i < env_records; env++) {
     char *thisEnv = *env;
     char *aux = malloc(strlen(thisEnv) + 1);
@@ -912,8 +934,10 @@ static int start_component(zl_comp_t *comp) {
   int fd_count = 3;
   int fd_map[3];
   char bin[PATH_MAX];
+  char js_path[PATH_MAX];

-  snprintf(bin, sizeof(bin), "%s/bin/zwe", zl_context.root_dir);
+  snprintf(bin, sizeof(bin), "%s/bin/utils/configmgr", zl_context.root_dir);
+  snprintf(js_path, sizeof(js_path), "%s/bin/commands/internal/start/component/cli.js", zl_context.root_dir);
   script = fopen(bin, "r");
   if (script == NULL) {
     DEBUG("script not open for %s - %s\n", comp->name, strerror(errno));
@@ -926,15 +950,11 @@ static int start_component(zl_comp_t *comp) {

   DEBUG("%s fd_map[0]=%d, fd_map[1]=%d, fd_map[2]=%d\n",
         comp->name, fd_map[0], fd_map[1], fd_map[2]);
-
+  
   const char *c_args[] = {
     bin,
-    "internal",
-    "start",
-    "component",
-    "--config", zl_context.config_path,
-    "--ha-instance", zl_context.ha_instance_id,
-    "--component", comp->name, 
+    "-script",
+    js_path,
     NULL
   };

[1000TurquoisePogs]

Here is a test I did to prove you can just run configmgr scripts directly if you have the right env vars.

How to test this design? You can just have your ZWESLSTC job defined with a YAML that has a single component enabled like "zss" and see if zss starts up the same as it did before this change.

[1000TurquoisePogs]

Completed for v2.17.0