{"id":12358,"date":"2019-04-13T12:00:22","date_gmt":"2019-04-13T10:00:22","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/"},"modified":"2025-10-24T09:32:16","modified_gmt":"2025-10-24T07:32:16","slug":"how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/","title":{"rendered":"How to stop Documentum processes in a docker container, and more (part II)"},"content":{"rendered":"

ok, Ok, OK, and the docker part ?<\/h2>\n

In a minute.
\nIn part I<\/a> of this 2-part article, we showed how traps could be used to control a running executable from the outside. We also presented a bash test script to try out and play with traps. Now that we are confident about that simulation script, let’s dockerize it and try it out in this new environment. We use the dockerfile Dockerfile-dctm to create the CS image and so we include an ENTRYPOINT clause as follows:<\/p>\n

\nFROM ubuntu:latest\nRUN apt-get update &&      \n    apt-get install -y gawk\nCOPY dctm.sh \/root\/.\nENTRYPOINT [\"\/root\/dctm.sh\", \"start\"]\n<\/pre>\n
The above ENTRYPOINT syntax allows to run the dctm.sh script with PID 1 because the initial bash process (which runs with PID 1 obviously) performs an exec call to load and execute that script. To keep the dockerfile simple, the script will run as root. In the real-world, CS processes run as something like dmadmin, so this account would have to be set up in the dockerfile (or through some orchestration software).
\nWhen the docker image is run or the container is started, the dctm.sh script gets executed with PID 1; as the script is invoked with the start option, it starts the processes. Afterwards, it justs sits there waiting for the SIGTERM signal from the docker stop  command; once received, it shuts down all the running processes under its control and exits, which will also stop the container’s process. Additionaly, it can listen and react to some other signals, just like when it runs outside of a container.<\/p>\n
Testing<\/h2>\n
Let’s test this approach with a container built using the above simple Dockerfile-dctm. Since the container is started in interactive mode, its output is visible on the screen and the commands to test it have to be sent from another terminal session; as before, for clarity, the commands have been inserted in the transcript as comments right before their result.
\n
\ndocker build -f Dockerfile-dctm --tag=dctm .<\/strong>
\nSending build context to Docker daemon  6.656kB
\nStep 1\/5 : FROM ubuntu:latest
\n ---> 1d9c17228a9e
\nStep 2\/5 : RUN apt-get update &&     apt-get install -y gawk
\n ---> Using cache
\n ---> f550d88161b6
\nStep 3\/5 : COPY dctm.sh \/root\/.
\n ---> e15e3f4ea93c
\nStep 4\/5 : HEALTHCHECK --interval=5s --timeout=2s --retries=1 CMD grep -q OK \/tmp\/status || exit 1
\n ---> Running in 0cea23cec09e
\nRemoving intermediate container 0cea23cec09e
\n ---> f9bf4138eb83
\nStep 5\/5 : ENTRYPOINT [\"\/root\/dctm.sh\", \"start\"]
\n ---> Running in 670c5231d5d8
\nRemoving intermediate container 670c5231d5d8
\n ---> 27991672905e
\nSuccessfully built 27991672905e
\nSuccessfully tagged dctm:latest
\n 
\n# docker run -i --name=dctm dctm<\/strong>
\nprocess started with pid 9 and random value 32760057
\nprocess started with pid 10 and random value 10364519
\nprocess started with pid 11 and random value 2915264
\nprocess started with pid 12 and random value 3744070
\nprocess started with pid 13 and random value 23787621
\n5 processes started
\n 
\nstarted processes:
\n    1     9     1     1 ?           -1 S        0   0:00 I am number 32760057
\n    1    10     1     1 ?           -1 S        0   0:00 I am number 10364519
\n    1    11     1     1 ?           -1 S        0   0:00 I am number 2915264
\n    1    12     1     1 ?           -1 S        0   0:00 I am number 3744070
\n    1    13     1     1 ?           -1 S        0   0:00 I am number 23787621
\n 
\nsend signal SIGURG for help
\nsend signal SIGPWR to start a few processes
\nsend signal SIGUSR1 to start a new process
\nsend signal SIGUSR2 for the list of started processes
\nsend signal SIGINT | SIGABRT to stop all the processes
\nsend signal SIGHUP | SIGQUIT | SIGTERM to shutdown the processes and exit the container
\n 
\n# docker kill --signal=SIGUSR2 dctm<\/strong>
\nstatus of running processes at 2019\/04\/06 14:56:14
\nshowing 32760057
\nrandom value 32760057 is used by process with pid 9 and pgid 1
\nshowing 10364519
\nrandom value 10364519 is used by process with pid 10 and pgid 1
\nshowing 2915264
\nrandom value 2915264 is used by process with pid 11 and pgid 1
\nshowing 3744070
\nrandom value 3744070 is used by process with pid 12 and pgid 1
\nshowing 23787621
\nrandom value 23787621 is used by process with pid 13 and pgid 1
\n5 processes found
\n 
\n# docker kill --signal=SIGURG dctm<\/strong>
\nsend signal SIGURG for help
\nsend signal SIGPWR to start a few processes
\nsend signal SIGUSR1 to start a new process
\nsend signal SIGUSR2 for the list of started processes
\nsend signal SIGINT | SIGABRT to stop all the processes
\nsend signal SIGHUP | SIGQUIT | SIGTERM to shutdown the processes and exit the container
\n 
\n# docker kill --signal=SIGUSR1 dctm<\/strong>
\nstarting a new process at 2019\/04\/06 14:57:30
\nprocess started with pid 14607 and random value 10066771
\n 
\n# docker kill --signal=SIGABRT dctm<\/strong>
\nshutting down the processes at 2019\/04\/06 14:58:12
\nstopping 32760057
\nstopping 10364519
\nstopping 2915264
\nstopping 3744070
\nstopping 23787621
\nstopping 10066771
\n6 processes stopped
\n 
\n# docker kill --signal=SIGUSR2 dctm<\/strong>
\nstatus of running processes at 2019\/04\/06 14:59:01
\n0 processes found
\n 
\n# docker kill --signal=SIGTERM dctm<\/strong>
\nshutting down the container at 2019\/04\/06 14:59:19
\n 
\nshutting down the processes at 2019\/04\/06 14:59:19
\n0 processes stopped
\n 
\ndocker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
\n<\/code>
\nWe observe exactly the same behavior as the stand-alone dctm.sh, that’s comforting.
\nMoreover, when the container is stopped, the signal is trapped correctly by the proxy:
\n
\n...
\nrandom value 14725194 is used by process with pid 29 and pgid 1
\nshowing 12554300
\nrandom value 12554300 is used by process with pid 30 and pgid 1
\n5 processes found
\n 
\n# date -u +\"%Y\/%m\/%d %H:%M:%S\"; docker stop dctm<\/strong>
\n# 2019\/04\/10 22:51:47
\n# dctm
\nshutting down the container at 2019\/04\/10 22:51:47
\n 
\nshutting down the processes at 2019\/04\/10 22:51:47
\nstopping 36164161
\nstopping 6693775
\nstopping 11404415
\nstopping 14725194
\nstopping 12554300
\n5 processes stopped
\n<\/code>
\nThe good thing is that if the docker daemon is stopped at the host level, either interactively or at system shut down, the daemon first sends a SIGTERM to every running container:
\n
\ndate --utc +\"%Y\/%m\/%d %H-%M-%S\"; sudo systemctl stop docker
\n2019\/04\/06 15-02-18
\n[sudo] password for docker:
\n<\/code>
\nand on the other terminal:
\n
\nshutting down the container at 2019\/04\/06 15:02:39
\n 
\nshutting down the processes at 2019\/04\/06 15:02:39
\nstopping 17422702
\nstopping 30251419
\nstopping 14451888
\nstopping 14890733
\nstopping 1105445
\n5 processes stopped
\n<\/code>
\nso each container can process the signal accordingly to its needs. Our future Documentum container is now ready for a clean shutdown.<\/p>\n
Doing something useful instead of sitting idle: light monitoring<\/h2>\n
As said, the proxy script waits for a signal from within a loop; the action performed inside the loop is waiting for an input from stdin, which is not particularly useful. Why not taking advantage of this slot to make it do something useful like a monitoring of the running processes ? Such a function already exists in the script, it’s status_all(). Thus, let’s set this up:
\n
\n# while true; do read; done<\/del>
\n# do something useful instead;
\nwhile true; do
\n   status_all
\n   sleep 30
\ndone
\n<\/code>
\nWe quickly notice that their processing is not so briskly any more. In effect, bash waits before processing a signal until the command currently executing completes, here any command inside the loop, so a slight delay is perceptible before our signals get care of, especially if we are in the middle of a ‘sleep 600’ command. Moreover, incoming signals are not stacked up but they replace each one another until the most recent one only is processed. In practical conditions, this is not a problem for it is still possible to send signals and have them processed, just not in burst mode. If a better reactivity to signals is needed, the sleep duration should be shortened and\/or a separate scheduling of the monitoring be introduced (started asynchronously from a loop in the entrypoint or from a crontab inside the container ?).
\nNote that the status send to stdout from within a detached container (i.e. started without the -i for interactive option, which is generally the case) is not visible outside a container. Fortunately, and even better, the docker logs command makes it possible to view on demand the status output:
\n
\ndocker logs --follow container_name<\/em>
\n<\/code>
\nIn our case:
\n
\ndocker logs --follow dctm<\/strong>
\nstatus of running processes at 2019\/04\/06 15:21:21
\nshowing 8235843
\nrandom value 8235843 is used by process with pid 8 and pgid 1
\nshowing 16052839
\nrandom value 16052839 is used by process with pid 9 and pgid 1
\nshowing 1097668
\nrandom value 1097668 is used by process with pid 10 and pgid 1
\nshowing 5113933
\nrandom value 5113933 is used by process with pid 11 and pgid 1
\nshowing 1122110
\nrandom value 1122110 is used by process with pid 12 and pgid 1
\n5 processes found
\n<\/code>
\nNote too that the logs commands also has a timestamps option for prefixing the lines output with the time they were produced, as illustrated below:
\n
\ndocker logs --timestamps --since 2019-04-06T18:06:23 dctm<\/strong>
\n2019-04-06T18:06:23.607796640Z status of running processes at 2019\/04\/06 18:06:23
\n2019-04-06T18:06:23.613666475Z showing 7037074
\n2019-04-06T18:06:23.616334029Z random value 7037074 is used by process with pid 8 and pgid 1
\n2019-04-06T18:06:23.616355592Z showing 33446655
\n2019-04-06T18:06:23.623719975Z random value 33446655 is used by process with pid 9 and pgid 1
\n2019-04-06T18:06:23.623785755Z showing 17309380
\n2019-04-06T18:06:23.627050839Z random value 17309380 is used by process with pid 10 and pgid 1
\n2019-04-06T18:06:23.627094599Z showing 13859725
\n2019-04-06T18:06:23.630436025Z random value 13859725 is used by process with pid 11 and pgid 1
\n2019-04-06T18:06:23.630472176Z showing 26767323
\n2019-04-06T18:06:23.633304616Z random value 26767323 is used by process with pid 12 and pgid 1
\n2019-04-06T18:06:23.635900480Z 5 processes found
\n2019-04-06T18:06:26.640490424Z
\n<\/code>
\nThis is handy, but still not perfect, for those cases where lazy programmers neglect to date their logs’ entries.
\nNow, since we have a light-weight monitoring in place, we can use it in the dockerfile’s HEALTHCHECK clause to show the container’s status through the ps command. As the processes’ status is already determined in the wait loop of the dctm.sh script, it is pointless to compute it again. Instead, we can modify status_all() to print the overall status in a file, say in \/tmp\/status, so that HEALTHCHECK can read it later every $INTERVAL period. If status_all() is invoked every $STATUS_PERIOD, a race condition can occur every LeastCommonMultiple($INTERVAL, $STATUS_PERIOD), i.e. when these 2 processes will access the file simultaneously, the former in reading mode and the latter in writing mode. To avoid this nasty situation, status_all() will first write into \/tmp\/tmp_status and later rename this file to \/tmp\/status. For the sake of our example, let’s decide that the container is unhealthy if there are no dummy processes running, and healthy if there is at least one running (in real conditions, the container would be healthy if ALL the processes are responding, and unhealthy if ANY of them is not but it also depends on the definition of health). Here is the new dctm.sh’s status_all() function:<\/p>\n
\nstatus_all() {\n   echo; echo \"status of running processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   nb_processes=0\n   for no in $(ps -ef | grep \"I am number \" | grep -v grep | gawk '{print $NF}'); do\n      echo \"showing $no\"\n      func status $no\n      (( nb_processes++ ))\n   done\n   echo \"$nb_processes processes found\"\n   if [[ $nb_processes -eq 0 ]]; then\n      printf \"status: badn\" > \/tmp\/tmp_status\n   else\n      printf \"status: OKn\" > \/tmp\/tmp_status\n   fi\n   mv \/tmp\/tmp_status \/tmp\/status\n}\n<\/pre>\n
Here is the new dockerfile:<\/p>\n
\nFROM ubuntu:latest\nRUN apt-get update &&      \n    apt-get install -y gawk\nCOPY dctm.sh \/root\/.\nHEALTHCHECK --interval=10s --timeout=2s --retries=2 CMD grep -q OK \/tmp\/status || exit 1\nENTRYPOINT [\"\/root\/dctm.sh\", \"start\"]\n<\/pre>\n
Here is what the ps commands shows now:
\n
\n# docker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                            PORTS               NAMES
\n64e22a8f75cd        dctm                \"\/root\/dctm.sh start\"   38 minutes ago      Up 2 seconds (health: starting<\/strong>)                       dctm
\n 
\n...
\n# docker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                   PORTS               NAMES
\n64e22a8f75cd        dctm                \"\/root\/dctm.sh start\"   38 minutes ago      Up 6 seconds (healthy<\/strong>)                       dctm
\n<\/code>
\nA new column, STATUS, is displayed showing the container’s current health status.
\nIf a new built is unwanted, the clause can be specified when running the image:
\n
\ndocker run --name dctm --health-cmd \"grep -q OK \/tmp\/status || exit 1\" --health-interval=10s --health-timeout=2s --health-retries=1 dctm
\n<\/code>
\nNote how these parameters are now prefixed with “health-” so they can be related to the HEALTHCHECK clause.
\nNow, in order to observe how the status is updated, let’s play with the signals INT and PWR to respectively stop and launch processes inside the container:
\n
\n# current situation:
\ndocker logs dctm<\/strong>
\nstatus of running processes at 2019\/04\/12 14:05:00
\nshowing 29040429
\nrandom value 29040429 is used by process with pid 1294 and pgid 1
\nshowing 34302125
\nrandom value 34302125 is used by process with pid 1295 and pgid 1
\nshowing 2979702
\nrandom value 2979702 is used by process with pid 1296 and pgid 1
\nshowing 4661756
\nrandom value 4661756 is used by process with pid 1297 and pgid 1
\nshowing 7169283
\nrandom value 7169283 is used by process with pid 1298 and pgid 1
\n5 processes found
\n 
\n# show status:
\ndocker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                    PORTS               NAMES
\nff25beae71f0        dctm                \"\/root\/dctm.sh start\"   55 minutes ago      Up 55 minutes (healthy<\/strong>)                       dctm
\n 
\n# stop the processes:
\ndocker kill --signal=SIGINT dctm<\/strong>
\n# wait up to the given health-interval and check again:
\n# docker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                      PORTS               NAMES
\nff25beae71f0        dctm                \"\/root\/dctm.sh start\"   57 minutes ago      Up 57 minutes (unhealthy<\/strong>)                       dctm
\n 
\n# restart the processes:
\ndocker kill --signal=SIGPWR dctm<\/strong>
\n 
\n# wait up to the health-interval and check again:
\ndocker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                       PORTS               NAMES
\nff25beae71f0        dctm                \"\/root\/dctm.sh start\"   About an hour ago   Up About an hour (healthy<\/strong>)                       dctm
\n<\/code>
\nThe healthstatus command works as expected.
\nNote that the above HEALTHCHECK successful tests were done under Centos Linux release 7.6.1810 (Core) with docker Client Version 1.13.1 and API version 1.26, Server Version 1.13.1 and API version 1.26 (minimum version 1.12).
\nThe HEALTHCHECK clause looks broken under Ubuntu 18.04.1 LTS with docker Client Version 18.09.1 and API version 1.39, Server Engine – Community Engine Version 18.09.1 and API version 1.39 (minimum version 1.12). After a change of status, HEALTHCHECK sticks to the unhealthy state and “docker ps” always shows “healthy” no matter the following changes in the running processes inside the container. It looks like the monitoring cycles until an unhealthy condition occurs, then it stops cycling and stays in the unhealthy state, as it is also visible in the timestamps by inspecting the container’s status:
\n
\ndocker inspect --format='{{json .State.Health}}' dctm
\n{\"Status\":\"unhealthy\",\"FailingStreak\":0,\"Log\":[{\"Start\":\"2019-04-12T16:04:18.995957081+02:00\",\"End\":\"2019-04-12T16:04:19.095540448+02:00\",\"ExitCode\":0,\"Output\":\"\"},
\n{\"Start\":\"2019-04-12T16:04:21.102151004+02:00\",\"End\":\"2019-04-12T16:04:21.252025292+02:00\",\"ExitCode\":0,\"Output\":\"\"},
\n{\"Start\":\"2019-04-12T16:04:23.265929424+02:00\",\"End\":\"2019-04-12T16:04:23.363387974+02:00\",\"ExitCode\":0,\"Output\":\"\"},
\n{\"Start\":\"2019-04-12T16:04:25.372757042+02:00\",\"End\":\"2019-04-12T16:04:25.471229004+02:00\",\"ExitCode\":0,\"Output\":\"\"},
\n{\"Start\":\"2019-04-12T16:04:27.47692396+02:00\",\"End\":\"2019-04-12T16:04:27.580458001+02:00\",\"ExitCode\":0,\"Output\":\"\"}]}
\n<\/code>
\nThe last 5 entries stop being updated.
\nWhile we are mentioning bugs, “docker logs –tail 0 dctm” under Centos displays the whole log available so far, so specify 1 at least to reduce the output of the log history to a minimum. Under Ubuntu, it works as expected though. However, the “–follow” option works under Centos but not under Ubuntu. So, there is some instability here; be prepared to comprehensively test every docker’s feature to be used.<\/p>\n
Using docker’s built-in init process<\/h2>\n
As said above, docker does not have a full-fledged init process like systemd but still offers something vaguely related, tini, which stands for “tiny init”, see here<\/a>. It wont’t solve the inability of Documentum’s processes to respond to signals and therefore the proxy script is still needed. However, in addition to forwarding signals to its child process, tini has the advantage of taking care of defunct processes, or zombies, by reaping them up regularly. Documentum produces a lot of them and they finish up disappearing in the long run. Still, tini could speeds this up a little bit.
\ntini can be invoked from the command-line as follows:
\n
\ndocker run -i --name=dctm --init dctm
\n<\/code>
\nBut it is also possible to integrate it directly in the dockerfile so the −−init option won’t be needed any longer (and shouldn’t be used otherwise tini will not be PID 1 and its reaping feature won’t be possible anymore, making it useless for us):<\/p>\n
\nFROM ubuntu:latest\nCOPY dctm.sh \/root\/.\nENV TINI_VERSION v0.18.0\nADD https:\/\/github.com\/krallin\/tini\/releases\/download\/${TINI_VERSION}\/tini \/tini\nRUN apt-get update &&      \n    apt-get install -y gawk &&      \n    chmod +x \/tini\nHEALTHCHECK --interval=10s --timeout=2s --retries=2 CMD grep -q OK \/tmp\/status || exit 1\nENTRYPOINT [\"\/tini\", \"--\"]\n# let tini launch the proxy;\nCMD [\"\/root\/dctm.sh\", \"start\"]\n<\/pre>\n
Let’s build the image with tini:
\n
\ndocker build -f Dockerfile-dctm --tag=dctm:with-tini .<\/strong>
\nSending build context to Docker daemon  6.656kB
\nStep 1\/8 : FROM ubuntu:latest
\n ---> 1d9c17228a9e
\nStep 2\/8 : COPY dctm.sh \/root\/.
\n ---> a724637581fe
\nStep 3\/8 : ENV TINI_VERSION v0.18.0
\n ---> Running in b7727fc065e9
\nRemoving intermediate container b7727fc065e9
\n ---> d1e1a17d7255
\nStep 4\/8 : ADD https:\/\/github.com\/krallin\/tini\/releases\/download\/${TINI_VERSION}\/tini \/tini
\nDownloading [==================================================>]  24.06kB\/24.06kB
\n ---> 47b1fc9f82c7
\nStep 5\/8 : RUN apt-get update &&              apt-get install -y gawk &&     chmod +x \/tini
\n ---> Running in 4543b6f627f3
\nGet:1 http:\/\/security.ubuntu.com\/ubuntu bionic-security InRelease [88.7 kB]
\nGet:2 http:\/\/archive.ubuntu.com\/ubuntu bionic InRelease [242 kB]
\n...
\nStep 6\/8 : HEALTHCHECK --interval=5s --timeout=2s --retries=1 CMD grep -q OK \/tmp\/status || exit 1
\n ---> Running in d2025cbde647
\nRemoving intermediate container d2025cbde647
\n ---> a17fd24c4819
\nStep 7\/8 : ENTRYPOINT [\"\/tini\", \"--\"]
\n ---> Running in ee1e10062f22
\nRemoving intermediate container ee1e10062f22
\n ---> f343d21175d9
\nStep 8\/8 : CMD [\"\/root\/dctm.sh\", \"start\"]
\n ---> Running in 6d41f591e122
\nRemoving intermediate container 6d41f591e122
\n ---> 66541b8c7b37
\nSuccessfully built 66541b8c7b37
\nSuccessfully tagged dctm:with-tini
\n<\/code>
\nLet’s run the image:
\n
\ndocker run -i --name=dctm dctm:with-tini<\/strong>
\n 
\nstarting a few processes at 2019\/04\/07 11:55:30
\nprocess started with pid 9 and random value 23970936
\nprocess started with pid 10 and random value 35538668
\nprocess started with pid 11 and random value 12039907
\nprocess started with pid 12 and random value 21444522
\nprocess started with pid 13 and random value 7681454
\n5 processes started
\n...
\n<\/code>
\nAnd let’s see how the container’s processes look like with tini from another terminal:
\n
\ndocker exec -it dctm \/bin\/bash<\/strong>
\nps -ef
\nUID        PID  PPID  C STIME TTY          TIME CMD
\nroot         1     0  0 11:55 ?        00:00:00 \/tini -- \/root\/dctm.sh start
\nroot         6     1  0 11:55 ?        00:00:00 \/bin\/bash \/root\/dctm.sh start
\nroot         9     6  0 11:55 ?        00:00:00 I am number 23970936
\nroot        10     6  0 11:55 ?        00:00:00 I am number 35538668
\nroot        11     6  0 11:55 ?        00:00:00 I am number 12039907
\nroot        12     6  0 11:55 ?        00:00:00 I am number 21444522
\nroot        13     6  0 11:55 ?        00:00:00 I am number 7681454
\nroot       174     0  0 11:55 ?        00:00:00 \/bin\/bash
\nroot       201     6  0 11:55 ?        00:00:00 sleep 3
\nroot       208   174  0 11:55 ?        00:00:00 ps -ef
\n...
\n<\/code>
\nSo tini is really running with PID == 1 and has started the proxy as its child process as expected.
\nLet’s test the container by sending a few signals:
\n
\ndocker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                   PORTS               NAMES
\n5f745485a907        dctm:with-tini      \"\/tini -- \/root\/dctm\u2026\"   8 seconds ago       Up 7 seconds (healthy)                       dctm
\n 
\n# docker kill --signal=SIGINT dctm<\/strong>
\nshutting down the processes at 2019\/04\/07 11:59:42
\nstopping 23970936
\nstopping 35538668
\nstopping 12039907
\nstopping 21444522
\nstopping 7681454
\n5 processes stopped
\n 
\nstatus of running processes at 2019\/04\/07 11:59:42
\n0 processes found
\n 
\nstatus of running processes at 2019\/04\/07 11:59:45
\n0 processes found
\n 
\n# docker kill --signal=SIGTERM dctm<\/strong>
\nshutting down the processes at 2019\/04\/07 12:00:00
\n0 processes stopped
\n<\/code>
\nand then the container gets stopped. So, the signals are well transmitted to tini’s child process.
\nIf one prefers to use the run’s −−init option instead of modifying the dockerfile and introduce tini as the ENTRYPOINT, it is even better because we will have only one version of the dockerfile to maintain. Here is the invocation and how the processes will look like:
\n
\ndocker run --name=dctm --init dctm<\/strong>
\ndocker ps<\/strong>
\nCONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS                            PORTS               NAMES
\n1d9fa0d98817        dctm                \"\/root\/dctm.sh start\"   4 seconds ago       Up 3 seconds (health: starting)                       dctm
\ndocker exec dctm \/bin\/bash -c \"ps -ef\"<\/strong>
\nUID        PID  PPID  C STIME TTY          TIME CMD
\nroot         1     0  0 12:11 ?        00:00:00 \/dev\/init -- \/root\/dctm.sh start
\nroot         6     1  0 12:11 ?        00:00:00 \/bin\/bash \/root\/dctm.sh start
\nroot         9     6  0 12:11 ?        00:00:00 I am number 23850948
\nroot        10     6  0 12:11 ?        00:00:00 I am number 19493606
\nroot        11     6  0 12:11 ?        00:00:00 I am number 34535435
\nroot        12     6  0 12:11 ?        00:00:00 I am number 32571187
\nroot        13     6  0 12:11 ?        00:00:00 I am number 35596440
\nroot       116     0  1 12:11 ?        00:00:00 \/bin\/bash
\nroot       143     6  0 12:11 ?        00:00:00 sleep 3
\nroot       144   116  0 12:11 ?        00:00:00 ps -ef
\n<\/code>
\nIt looks even better; tini is still there – presumably – but hidden behind \/dev\/init so the container will be immune to any future change in the default init process.<\/p>\n
Adapting dctm.sh for Documentum<\/h2>\n
Adapting the proxy script to a real Documentum installation with its own central stop\/start\/status script, let’s name it dctm_stop_start.sh, is easy. The main changes are limited to the func() function; now, it just relays the commands to the script dctm_stop_start.sh:<\/p>\n
\n#!\/bin\/bash\n# launches in the background, or stops or queries the status of, the Documentum dctm_start_stop.sh script;\n# Usage:\n#   .\/dctm.sh stop | start | status\n# e.g.:\n# $ .\/dctm.sh start\n# cec - dbi-services - April 2019\n#\ntrap 'help'         SIGURG\ntrap 'start_all'    SIGPWR\ntrap 'status_all'   SIGUSR2\ntrap 'stop_all'     SIGINT SIGABRT\ntrap 'shutdown_all' SIGHUP SIGQUIT SIGTERM\n\nverb=\"sleep\"\nexport id_prefix=\"I am number\"\n\nfunc() {\n   cmd=\"$1\"\n   case $cmd in\n      start)\n         .\/dctm_start_stop.sh start &\n         ;;\n      stop)\n         .\/dctm_start_stop.sh stop &\n         ;;\n      status)\n         .\/dctm_start_stop.sh status\n         return $?\n         ;;\n   esac\n}\n\nhelp() {\n   echo\n   echo \"send signal SIGURG for help\"\n   echo \"send signal SIGPWR to start the Documentum processes\"\n   echo \"send signal SIGUSR2 for the list of Documentum started processes\"\n   echo \"send signal SIGINT | SIGABRT to stop all the processes\"\n   echo \"send signal SIGHUP | SIGQUIT | SIGTERM to shutdown the Documentum processes and exit the container\"\n}\n\nstart_all() {\n   echo; echo \"starting the Documentum processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   func start\n}\n\nstatus_all() {\n   echo; echo \"status of Documentum processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   func status\n   if [[ $? -eq 0 ]]; then\n      printf \"status: badn\" > \/tmp\/tmp_status\n   else\n      printf \"status: OKn\" > \/tmp\/tmp_status\n   fi\n   mv \/tmp\/tmp_status \/tmp\/status\n}\n\nstop_all() {\n   echo; echo \"shutting down the Documentum processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   func stop\n}\n\nshutdown_all() {\n   echo; echo \"shutting down the container at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   stop_all\n   exit 0\n}\n\n# -----------\n# main;\n# -----------\n\n# starts a few dummy processes;\n[[ \"$1\" = \"start\" ]] && start_all\n\n# make sure the container stays up and waits for signals;\nwhile true; do status_all; sleep 3; done\n<\/pre>\n
Here is a skeleton of the script dctm_start_stop.sh:<\/p>\n
\n#!\/bin\/bash\n   cmd=\"$1\"\n   case $cmd in\n      start)\n         # insert here your Documentum installation's start scripts, e.g.\n         # \/app\/dctm\/dba\/dm_launch_Docbroker\n         # \/app\/dctm\/dba\/dm_start_testdb\n         # \/app\/dctm\/shared\/wildfly9.0.1\/server\/startMethodServer.sh &\n         echo \"started\"\n         ;;\n      stop)\n         # insert here your Documentum installation's stop scripts, e.g.\n         # \/app\/dctm\/shared\/wildfly9.0.1\/server\/stopMethodServer.sh\n         # \/app\/dctm\/dba\/dm_shutdown_testdb\n         # \/app\/dctm\/dba\/dm_stop_Docbroker\n         echo \"stopped\"\n         ;;\n      status)\n         # insert here your statements to test the Documentum processes's health;\n         # e.g. dmqdocbroker -c -p 1489 ....\n         # e.g. idql testdb -Udmadmin -Pxxx to try to connect to the docbase;\n         # e.g. wget http:\/\/localhost:9080\/... to test the method server;\n         # 0: OK, 1: NOK;\n         exit 0\n         ;;\n   esac\n<\/pre>\n
Let’s introduce a slight modification in the dockerfile’s entrypoint clause: instead of having the Documentum processes start at container startup, the container will start with only the proxy running inside. Only upon receiving the signal SIGPWR will the proxy start all the Documentum processes:<\/p>\n
\nENTRYPOINT [\"\/root\/dctm.sh\", \"\"]\n<\/pre>\n
If the light-weight monitoring is in action, the container will be flagged unhealthy but this can be an useful reminder.
\nNote that the monitoring could be activated or deactivated through a signal as showed in the diff output below:<\/p>\n
\ndiff dctm-no-monitoring.sh dctm.sh\n21a22\n> trap 'status_on_off' SIGCONT\n24a26\n> bStatus=1\n119a122,125\n> status_on_off() {\n>    (( bStatus = (bStatus + 1) % 2 ))\n> }\n> \n132c138\n    [[ $bStatus -eq 1 ]] && status_all\n<\/pre>\n
This is more flexible and better matches the reality.<\/p>\n
Shortening docker commands<\/h2>\n
We have thrown a lot of docker commands at you. If they are used often, their verbosity can be alleviated through aliases, e.g.:
\n
\nalias di='docker images'
\nalias dpsas='docker ps -as'
\nalias dps='docker ps'
\nalias dstatus='docker kill --signal=SIGUSR2'
\nalias dterm='docker kill --signal=SIGTERM'
\nalias dabort='docker kill --signal=SIGABRT'
\nalias dlogs='docker logs --follow'
\nalias dstart='docker start'
\nalias dstarti='docker start -i'
\nalias dstop=\"docker stop\"
\nalias drm='docker container rm'
\n<\/code>
\nor even bash functions for the most complicated ones (to be appended into e.g. your ~\/.bashrc):
\n
\nfunction drun {
\n   image=\"$1\"
\n   docker run -i --name=$image $image
\n}
\n 
\nfunction dkill {
\n   signal=$1
\n   container=$2
\n   docker kill --signal=$signal $container
\n}
\n 
\nfunction dbuild {
\n   docker build -f Dockerfile-dctm --tag=$1 .
\n}
\n<\/code>
\nThe typical sequence for testing the dockerfile Dockerfile-dctm to produce the image dctm and run it as the dctm container is:
\n
\ndbuild dctm
\ndrm dctm
\ndrun dctm
\n<\/code>
\nMuch less typing.<\/p>\n
Conclusion<\/h2>\n
At the end of the day, it is no such a big deal that the Documentum CS does not process signals sent to it for it is easy to work around this omission and even go beyond the basic stops and starts. As always, missing features or shortcomings become a source of inspiration and enhancements !
\nContainerization has lots of advantages but we have noticed that docker’s implementations vary between versions and platforms so some features don’t always work as expected, if at all.
\nIn a future blog, I’ll show a containerization of the out of the box CS that includes signal trapping. In the meantime, live long and don’t despair.<\/p>\n","protected":false},"excerpt":{"rendered":"
ok, Ok, OK, and the docker part ? In a minute. In part I of this 2-part article, we showed how traps could be used to control a running executable from the outside. We also presented a bash test script to try out and play with traps. Now that we are confident about that simulation […]<\/p>\n","protected":false},"author":40,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,525],"tags":[],"type_dbi":[],"class_list":["post-12358","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","category-enterprise-content-management"],"acf":[],"yoast_head":"\nHow to stop Documentum processes in a docker container, and more (part II) - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"How to stop Documentum processes in a docker container, and more (part II)\" \/>\n<meta property=\"og:description\" content=\"ok, Ok, OK, and the docker part ? In a minute. In part I of this 2-part article, we showed how traps could be used to control a running executable from the outside. We also presented a bash test script to try out and play with traps. Now that we are confident about that simulation […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2019-04-13T10:00:22+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-24T07:32:16+00:00\" \/>\n<meta name=\"author\" content=\"Middleware Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Middleware Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\"},\"author\":{\"name\":\"Middleware Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1\"},\"headline\":\"How to stop Documentum processes in a docker container, and more (part II)\",\"datePublished\":\"2019-04-13T10:00:22+00:00\",\"dateModified\":\"2025-10-24T07:32:16+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\"},\"wordCount\":1880,\"commentCount\":0,\"articleSection\":[\"Database Administration & Monitoring\",\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\",\"name\":\"How to stop Documentum processes in a docker container, and more (part II) - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2019-04-13T10:00:22+00:00\",\"dateModified\":\"2025-10-24T07:32:16+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"How to stop Documentum processes in a docker container, and more (part II)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1\",\"name\":\"Middleware Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g\",\"caption\":\"Middleware Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/middleware-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"How to stop Documentum processes in a docker container, and more (part II) - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/","og_locale":"en_US","og_type":"article","og_title":"How to stop Documentum processes in a docker container, and more (part II)","og_description":"ok, Ok, OK, and the docker part ? In a minute. In part I of this 2-part article, we showed how traps could be used to control a running executable from the outside. We also presented a bash test script to try out and play with traps. Now that we are confident about that simulation […]","og_url":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/","og_site_name":"dbi Blog","article_published_time":"2019-04-13T10:00:22+00:00","article_modified_time":"2025-10-24T07:32:16+00:00","author":"Middleware Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Middleware Team","Est. reading time":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/"},"author":{"name":"Middleware Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"headline":"How to stop Documentum processes in a docker container, and more (part II)","datePublished":"2019-04-13T10:00:22+00:00","dateModified":"2025-10-24T07:32:16+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/"},"wordCount":1880,"commentCount":0,"articleSection":["Database Administration & Monitoring","Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/","url":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/","name":"How to stop Documentum processes in a docker container, and more (part II) - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2019-04-13T10:00:22+00:00","dateModified":"2025-10-24T07:32:16+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-ii\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"How to stop Documentum processes in a docker container, and more (part II)"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d8563acfc6e604cce6507f45bac0ea1","name":"Middleware Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/ddcae7ba0f9d1a0e7ae707f0e689e4a9c95bb48ec49c8e6d9cc86d43f4121cb6?s=96&d=mm&r=g","caption":"Middleware Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/middleware-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12358","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=12358"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12358\/revisions"}],"predecessor-version":[{"id":41188,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12358\/revisions\/41188"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=12358"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=12358"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=12358"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=12358"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}