It looks as if the crawlers that the java app starts the crawlers, which start the database monitors. When the crawler quits the parent of the database monitor becomes the java app, and it seems it isn't reaping the child processes. I'm not sure how that would be done in Java.
After the crawl finishes, I call rmlocks on the database within the java app. Is that when the java app becomes parent of the zombied monitor? Is the ppid for monitor normally the vortex crawl script?
Another thing I noticed, for the defunct monitor procs, I don't see a correlating pid in the monitor.log. Are these possibly being created by something else that wouldn't log it in monitor.log?
200 2023-01-26 03:55:04 (26255) Texis Monitor version 07.06.1531283897 starting as user root
100 2023-01-26 03:55:04 (26255) Warning: monitor running effectively as root
005 2023-01-26 03:55:04 (26255) Cannot open license file `/usr/local/morph3/license.key' for reading: No such file or directory
200 2023-01-26 03:55:04 (26255) Generating default Webinator license
200 2023-01-26 03:55:04 (26255) Successful license update from file
200 2023-01-26 03:55:04 (26257) Database Monitor on /usr/local/morph3/texis/testdb starting as user root
200 2023-01-26 05:01:27 (23) Texis Monitor version 07.06.1531283897 initializing as /usr/local/morph3/bin/monitor
200 2023-01-26 05:01:27 (24) Texis Monitor version 07.06.1531283897 starting as user txusr (init was PID 23)
200 2023-01-26 05:01:27 (26) Database Monitor on /usr/local/morph3/texis/testdb starting as user txusr
115 2023-01-26 05:01:28 (24) Certificate `/usr/local/morph3/conf/ssl/certs/licensemonitor.cert' for schedule/license server is a CA certificate (Basic Constraints: CA:TRUE): clients may expect a non-CA certificate in the function TXmonservSslUserPromptPrep
200 2023-01-26 05:01:30 (24) Contacting license server
200 2023-01-26 05:01:30 (24) Successful reply from license server: serial is 64782
200 2023-01-26 05:01:35 (71) Database Monitor on /mnt/data/ftp/qsend/5888fa129/postdb starting as user txusr
200 2023-01-26 05:01:35 (74) Database Monitor on /mnt/data/ftp/qsend/db starting as user txusr
The texis monitor processes normally daemonize, so they keep running, which is what gives them the parent process id of 1, which normally is init that will keep running, and handle the process termination. Using the init option to docker will get that same behavior, otherwise you'd either need the java process to be handling the child process cleanups, or some other wrapper that handles that and launches the java.
aitchon wrote: ↑Wed Jan 25, 2023 6:03 pm
After the crawl finishes, I call rmlocks on the database within the java app. Is that when the java app becomes parent of the zombied monitor? Is the ppid for monitor normally the vortex crawl script?
Another thing I noticed, for the defunct monitor procs, I don't see a correlating pid in the monitor.log. Are these possibly being created by something else that wouldn't log it in monitor.log?
It would probably be simpler to add the "init" flag to your docker. Otherwise you'll need to install curses 5 compatibility libs with apt or download them from https://ftp.thunderstone.com/pub/linux/