Closed 1000TurquoisePogs closed 2 months ago
build 5128 SUCCEEDED. Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8831911062
Test workflow 4381 is started. Running install test: Convenience Pax The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/2.16.0-PR-3812/zowe-2.16.0-pr-3812-5128-20240425114904.pax Running on machine: zzow07 Result: FAILURE Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8831984271
build 5131 SUCCEEDED. Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8845240297
Test workflow 4384 is started. Running install test: Convenience Pax The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/2.16.0-PR-3812/zowe-2.16.0-pr-3812-5131-20240426082644.pax Running on machine: zzow06 Result: SUCCESS Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8845369465
I tested and confirmed if i kill a server process the launcher understands it needs to restart it. so, seems like this code causes no regression.
Working fine on our system. I have noticed this node
message:
...
ZWESVUSR INFO ZWEL0069I Configuration is valid
ZWESVUSR INFO ZWEL0058I WORKSPACE_DIR is '/zowe/workspace'
FSUM7422 node is not found
Node found in NODE_HOME
ZWESVUSR INFO (zwe-internal-start-prepare) Zowe version: v2.16.0
ZWESVUSR INFO (zwe-internal-start-prepare) build and hash: PR-3812#5131 (008872531f2a6ba28a8264e6f05266422d246d7b)
...
I think the "node not found" came from the PR where node was removed as a prereq. Some code somewhere must be checking for it and then complaining, yet continuing anyway.
build 5140 SUCCEEDED. Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8878212985
Error message assigned. Node warning found and corrected here https://github.com/zowe/zlux-app-server/pull/301
Test workflow 4399 is started. Running install test: Convenience Pax The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/2.16.0-PR-3812/zowe-2.16.0-pr-3812-5140-20240429121125.pax Running on machine: zzow08 Result: SUCCESS Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8878303647
build 5141 SUCCEEDED. Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8881219601
Test workflow 4400 is started. Running install test: Convenience Pax The zowe artifact being used by this test workflow: libs-snapshot-local/org/zowe/2.16.0-PR-3812/zowe-2.16.0-pr-3812-5141-20240429153423.pax Running on machine: zzow07 Result: SUCCESS Link to workflow run: https://github.com/zowe/zowe-install-packaging/actions/runs/8881347947
When inspecting for optimizations and reduction of shell usage for TMPDIR troubleshooting, I noticed that there's some unneeded use of shell wrappers for running each server.
In the code today, each time a start.sh of a server is run we spawn a shell to run that in, and then pipe its contents to ANOTHER shell so that we can put
wait
at the end.We could have just spawned one shell with that pipe, instead of a shell-within-a-shell. This looks to be largely from the old non-configmgr code, and configmgr can just further optimize.
The process tree goes from 7 processes in the case of zss:![before](https://github.com/zowe/zowe-install-packaging/assets/30730276/e2d18d1f-c58c-4a3e-9cb1-2a1af053b740)
To 6:![after](https://github.com/zowe/zowe-install-packaging/assets/30730276/4c3812b1-723a-4db4-bb18-6c7ecb410ec5)
An effort here can further reduce it to 5 https://github.com/zowe/launcher/issues/109 With both efforts combined, the tree of a given Zowe server would just be
But today it is
How to test this PR? If the servers come up the same as they did before, success. If a server is crashed (intentionally or unintentionally), launcher should have the same restart behavior as before.