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

Ideally, but not mandatorily, the management of Documentum processes is performed at the service level, e.g. by systemd. In my blog here<\/a>, I showed how to configure init files for Documentum under systemd. But containers don’t have systemd, yet. They just run processes, often only one, sometimes more if they are closely related together (e.g. the docbroker, the method server and the content servers), so how to replicate the same functionality with containers ?
\nThe topic of stopping processes in a docker container is abundantly discussed on-line (see for example the excellent article here<\/a>). O\/S signals are the magic solution so much so that I should have entitled this blog “Fun with the Signals” really !
\nI’ll simply see here if the presented approach can be applied in the particular case of a dockerized Documentum server. However, in order to keep things simple and quick, I won’t test such a real dockerized Documentum installation but rather use a script to simulate the Documentum processes, or any other processes at that since it is so generic.
\nBut first, why bother with this matter ? During all the years that I have been administrating repositories I’ve never noticed anything going wrong after restarting a suddenly stopped server, be it after an intentional kill, a pesky crash or an unplanned database unavailability. Evidently, the content server (CS henceforth) seems quite robust in this respect. Or maybe we were simply lucky so far. Personally, I don’t feel confident if I don’t shut down cleanly a process or service that must be stopped; some data might be still buffered in the CS’ memory and not flushing them properly might introduce inconsistencies or even corruptions. The same goes when an unsuspected multi-step operation is started and aborted abruptly in the middle; ideally, transactions, if they are used, exist for this purpose but anything can go wrong during rollback. Killing a process is like slamming a door, it produces a lot of noise, vibrations in the walls, even damages in the long run and always leaves a bad impression behind. Isn’t it more comforting to clean up and shut the door gently ? Even then something can go wrong but at least it will be through no fault of our own.<\/p>\n

A few Reminders<\/h2>\n

When a “docker container stop” is issued, docker sends the SIGTERM signal to the process with PID == 1 running inside the container. That process, if programmed to do so, can then react to the signal and do anything seen fit, typically shutting the running processes down cleanly. After a 10 seconds grace period, the container is stopped manu militari. In the case of Documentum processes, to put it politely, they don’t give a hoot to signals, except of course to the well-known, unceremonious SIGKILL one. Thus, a proxy process must be introduced which will accept the signal and invoke the proper shutdown scripts to stop the CS processes, usually the dm_shutdown_* and dm_stop_* scripts, or a generic one that takes care of everything, at start up and at shut down time.
\nSaid proxy must run with PID == 1 i.e. it must be the first one started in the container. Sort of, but even if it is not the very first, its PID 1 parent can pass it the control by using one of the exec() family functions; unlike forking a process, those in effect allow a child process to replace its parent under the latter’s PID, kind of like in the Matrix movies the agents Smith inject themselves into someone else’s persona, if you will ;-). The main thing being that at one point the proxy becomes PID 1. Luckily for us, we don’t have to bother with this complexity for the dockerfile’s ENTRYPOINT[] clause takes care of everything.
\nThe proxy also will be the one that starts the CS. In addition, since it must wait for the SIGTERM signal, it must never exit. It can indefinitely wait listening on a fake input (e.g. tail -f \/dev\/null), or wait for an illusory input in a detached container (e.g. while true; do read; done) or, better yet, do something useful like some light-weight monitoring.
\nWhile at it, the proxy process can listen to several conventional signals and react accordingly. For instance, a SIGUSR1 could mean “give me a docbroker docbase map” and a SIGUSR2 “restart the method server”. Admittedly, these actions could be done directly by just executing the relevant commands inside the container or from the outside command-line but the signal way is cheaper and, OK, funnier. So, let’s see how we can set all this up !<\/p>\n

The implementation<\/h2>\n

As said, in order to focus on our topic, i.e. signal trapping, we’ve replaced the CS part with a simple simulation script, dctm.sh, that starts, stops and queries the status of dummy processes. It uses the bash shell and has been written under linux. Here it is:<\/p>\n

\n#!\/bin\/bash\n# launches in the background, or stops or queries the status of, a command with a conventional identification string in the prompt;\n# the id is a random number determined during the start;\n# it should be passed to enquiry the status of the started process or to stop it;\n# Usage:\n#   .\/dctm.sh stop  | start | status \n# e.g.:\n# $ .\/dctm.sh start\n# | process started with pid 13562 and random value 33699963\n# $ psg 33699963\n# | docker   13562     1  0 23:39 pts\/0    00:00:00 I am number 33699963\n# $ .\/dctm.sh status 33699963\n# $ .\/dctm.sh stop 33699963\n#\n# cec - dbi-services - April 2019\n#\ntrap 'help'         SIGURG\ntrap 'start_all'    SIGPWR\ntrap 'start_one'    SIGUSR1\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         # do something that sticks forever-ish, min ca. 20mn;\n         (( params = 1111 * $RANDOM ))\n         exec -a \"$id_prefix\" $verb $params &\n         echo \"process started with pid $! and random value $params\"\n         ;;\n      stop)\n         params=\" $2\"\n         pid=$(ps -ajxf | gawk -v params=\"$params\" '{if (match($0, \" \" ENVIRON[\"id_prefix\"] params \"$\")) pid = $2} END {print (pid ? pid : \"\")}')\n         if [[ ! -z $pid ]]; then\n            kill -9 ${pid} &> \/dev\/null\n            wait ${pid} &> \/dev\/null\n         fi\n         ;;\n      status)\n         params=\" $2\"\n         read pid gid < <(ps -ajxf | gawk -v params="$params" '{if (match($0, " " ENVIRON["id_prefix"] params "$")) pid = $2 " " $3} END {print (pid ? pid : "")}')\n         if [[ ! -z $pid ]]; then\n            echo "random value${params} is used by process with pid $pid and pgid $gid"\n         else\n            echo "no such process running"\n         fi\n         ;;\n   esac\n}\n\nhelp() {\n   echo\n   echo "send signal SIGURG for help"\n   echo "send signal SIGPWR to start a few processes"\n   echo "send signal SIGUSR1 to start a new process"\n   echo "send signal SIGUSR2 for the list of started processes"\n   echo "send signal SIGINT | SIGABRT  to stop all the processes"\n   echo "send signal SIGHUP | SIGQUIT | SIGTERM to shutdown the processes and exit the container"\n}\n\nstart_all() {\n   echo; echo \"starting a few processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   for loop in $(seq 5); do\n      func start\n   done\n\n   # show them;\n   echo; echo "started processes"\n   ps -ajxf | grep "$id_prefix" | grep -v grep\n}\n\nstart_one() {\n   echo; echo \"starting a new process at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   func start\n}\n\nstatus_all() {\n   echo; echo \"status of running processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\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   done\n}\n\nstop_all() {\n   echo; echo \"shutting down the processes at $(date +\"%Y\/%m\/%d %H:%M:%S\")\"\n   for no in $(ps -ef | grep "I am number " | grep -v grep | gawk '{print $NF}'); do\n      echo "stopping $no"\n      func stop $no\n   done\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;\nstart_all\n\n# display some usage explanation;\nhelp\n\n# make sure the container stays up and waits for signals;\nwhile true; do read; done\n<\/pre>\n
The main part of the script starts a few processes, displays a help screen and then waits for input from stdin.
\nThe script can be first tested outside a container as follows.
\nRun the script:
\n
\n.\/dctm.sh
\n<\/code>
\nIt will start a few easily distinguishable processes and display a help screen:
\n
\nstarting a few processes at 2019\/04\/06 16:05:35
\nprocess started with pid 17621 and random value 19580264
\nprocess started with pid 17622 and random value 19094757
\nprocess started with pid 17623 and random value 18211512
\nprocess started with pid 17624 and random value 3680743
\nprocess started with pid 17625 and random value 18198180
\n 
\nstarted processes
\n17619 17621 17619  1994 pts\/0    17619 S+    1000   0:00  |       _ I am number 19580264
\n17619 17622 17619  1994 pts\/0    17619 S+    1000   0:00  |       _ I am number 19094757
\n17619 17623 17619  1994 pts\/0    17619 S+    1000   0:00  |       _ I am number 18211512
\n17619 17624 17619  1994 pts\/0    17619 S+    1000   0:00  |       _ I am number 3680743
\n17619 17625 17619  1994 pts\/0    17619 S+    1000   0:00  |       _ I am number 18198180
\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<\/code>
\nThen, it will simply sit there and wait until it is asked to quit.
\nFrom another terminal, let’s check the started processes:
\n
\nps -ef | grep \"I am number \" | grep -v grep
\ndocker   17621 17619  0 14:40 pts\/0    00:00:00 I am number 19580264
\ndocker   17622 17619  0 14:40 pts\/0    00:00:00 I am number 19094757
\ndocker   17623 17619  0 14:40 pts\/0    00:00:00 I am number 18211512
\ndocker   17624 17619  0 14:40 pts\/0    00:00:00 I am number 3680743
\ndocker   17625 17619  0 14:40 pts\/0    00:00:00 I am number 18198180
\n<\/code>
\nThose processes could be Documentum ones or anything else, the point here is to control them from the outside, e.g. another terminal session, in or out of a docker container. We will do that though O\/S signals. The bash shell lets a script listen and react to signals through the trap command. On top of the script, we have listed all the signals we’d like the script to react upon:<\/p>\n
\ntrap 'help'         SIGURG\ntrap 'start_all'    SIGPWR\ntrap 'start_one'    SIGUSR1\ntrap 'status_all'   SIGUSR2\ntrap 'stop_all'     SIGINT SIGABRT\ntrap 'shutdown_all' SIGHUP SIGQUIT SIGTERM\n<\/pre>\n
It’s really a feast of traps !
\nThe first line for example says that on receiving the SIGURG signal, the script’s function help() should be executed, no matter what the script was doing at that time, which in our case is just waiting for input from stdin.
\nThe SIGPWR signal is interpreted as start in the background another suite of five processes with the same naming convention “I am number ” followed with a random number. The function start_all() is called on receiving this signal.
\nThe SIGUSR1 signal starts one new process in the background. Function start_one() does just this.
\nThe SIGUSR2 signal displays all the started processes so far by invoking function status_all().
\nThe SIGINT and SIGABRT signals shut down all the started processes so far. Function stop_all() is called to this purpose.
\nFinally, signals SIGHUP, SIGQUIT, or SIGTERM all invokes function shutdown_all() to stop all the processes and exit the script.
\nAdmittedly, those signal’s choice is a bit stretched out but this is for the sake of the demonstration so bear with us. Feel free to remap the signals to the functions any way you prefer.
\nNow, how to send those signals ? The ill-named kill command or program is here for this. Despite its name, nobody will be killed here fortunately; signals will be sent and processes decide to react opportunely. Here, of course, we do react opportunely.
\nHere is its syntax (let’s use the −−long-options for clarity):
\n
\n\/bin\/kill --signal pid<\/em>
\n<\/code>
\nSince bash has a built-in kill command that behaves differently, make sure to call the right program by specifying  its full path name, \/bin\/kill.
\nExample of use:
\n
\n\/bin\/kill --signal SIGURG $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n# or shorter:
\n\/bin\/kill --signal SIGURG $(pgrep ^dctm.sh$)
\n<\/code>
\nThe signal’s target is our test program dctm.sh, which is identified vis a vis kill through its PID.
\nSignals can be specified by their full name, e.g. SIGURG, SIGPWR, etc… or without the SIG prefix such as URG, PWR, etc … or even through their numeric value as shown below:
\n
\n\/bin\/kill -L<\/strong>
\n 1 HUP      2 INT      3 QUIT     4 ILL      5 TRAP     6 ABRT     7 BUS
\n 8 FPE      9 KILL    10 USR1    11 SEGV    12 USR2    13 PIPE    14 ALRM
\n15 TERM    16 STKFLT  17 CHLD    18 CONT    19 STOP    20 TSTP    21 TTIN
\n22 TTOU    23 URG     24 XCPU    25 XFSZ    26 VTALRM  27 PROF    28 WINCH
\n29 POLL    30 PWR     31 SYS
\n 
\nor:
\n 
\nkill -L<\/strong>
\n 1) SIGHUP\t 2) SIGINT\t 3) SIGQUIT\t 4) SIGILL\t 5) SIGTRAP
\n 6) SIGABRT\t 7) SIGBUS\t 8) SIGFPE\t 9) SIGKILL\t10) SIGUSR1
\n11) SIGSEGV\t12) SIGUSR2\t13) SIGPIPE\t14) SIGALRM\t15) SIGTERM
\n16) SIGSTKFLT\t17) SIGCHLD\t18) SIGCONT\t19) SIGSTOP\t20) SIGTSTP
\n21) SIGTTIN\t22) SIGTTOU\t23) SIGURG\t24) SIGXCPU\t25) SIGXFSZ
\n26) SIGVTALRM\t27) SIGPROF\t28) SIGWINCH\t29) SIGIO\t30) SIGPWR
\n31) SIGSYS\t34) SIGRTMIN\t35) SIGRTMIN+1\t36) SIGRTMIN+2\t37) SIGRTMIN+3
\n38) SIGRTMIN+4\t39) SIGRTMIN+5\t40) SIGRTMIN+6\t41) SIGRTMIN+7\t42) SIGRTMIN+8
\n43) SIGRTMIN+9\t44) SIGRTMIN+10\t45) SIGRTMIN+11\t46) SIGRTMIN+12\t47) SIGRTMIN+13
\n48) SIGRTMIN+14\t49) SIGRTMIN+15\t50) SIGRTMAX-14\t51) SIGRTMAX-13\t52) SIGRTMAX-12
\n53) SIGRTMAX-11\t54) SIGRTMAX-10\t55) SIGRTMAX-9\t56) SIGRTMAX-8\t57) SIGRTMAX-7
\n58) SIGRTMAX-6\t59) SIGRTMAX-5\t60) SIGRTMAX-4\t61) SIGRTMAX-3\t62) SIGRTMAX-2
\n63) SIGRTMAX-1\t64) SIGRTMAX
\n<\/code>
\nThus, the following incantations are equivalent:
\n
\n\/bin\/kill --signal SIGURG $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal    URG $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal     23 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n<\/code>
\nOn receiving the supported signals, the related function is invoked and thereafter the script returns to its former activity, namely the loop that waits for a fake input. The loop is needed otherwise the script would exit on returning from a trap handler. In effect, the trap is processed like a function call and, on returning, the next statement at the point the trap occurred is given control. If there is none, then the script terminates. Hence the loop.
\nHere is the output after sending a few signals; for clarity, the signals sent from another terminal have been manually inserted as highlighted comments before the output they caused.
\nOutput terminal:
\n
\n# SIGUSR2:<\/strong>
\nstatus of running processes at 2019\/04\/06 16:12:46
\nshowing 28046084
\nrandom value 28046084 is used by process with pid 29248 and pgid 29245
\nshowing 977680
\nrandom value 977680 is used by process with pid 29249 and pgid 29245
\nshowing 26299592
\nrandom value 26299592 is used by process with pid 29250 and pgid 29245
\nshowing 25982957
\nrandom value 25982957 is used by process with pid 29251 and pgid 29245
\nshowing 27830550
\nrandom value 27830550 is used by process with pid 29252 and pgid 29245
\n5 processes found
\n 
\n# SIGUSR1:<\/strong>
\nstarting a new process at 2019\/04\/06 16:18:56
\nprocess started with pid 29618 and random value 22120010
\n 
\n# SIGUSR2:<\/strong>
\nstatus of running processes at 2019\/04\/06 16:18:56
\nshowing 28046084
\nrandom value 28046084 is used by process with pid 29248 and pgid 29245
\nshowing 977680
\nrandom value 977680 is used by process with pid 29249 and pgid 29245
\nshowing 26299592
\nrandom value 26299592 is used by process with pid 29250 and pgid 29245
\nshowing 25982957
\nrandom value 25982957 is used by process with pid 29251 and pgid 29245
\nshowing 27830550
\nrandom value 27830550 is used by process with pid 29252 and pgid 29245
\nshowing 22120010
\nrandom value 22120010 is used by process with pid 29618 and pgid 29245
\n6 processes found
\n 
\n# SIGURG:<\/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# SIGINT:<\/strong>
\nshutting down the processes at 2019\/04\/06 16:20:17
\nstopping 28046084
\nstopping 977680
\nstopping 26299592
\nstopping 25982957
\nstopping 27830550
\nstopping 22120010
\n6 processes stopped
\n 
\n# SIGUSR2:<\/strong>
\nstatus of running processes at 2019\/04\/06 16:20:18
\n0 processes found
\n 
\n# SIGPWR:<\/strong>
\nstarting a few processes at 2019\/04\/06 16:20:50
\nprocess started with pid 29959 and random value 2649735
\nprocess started with pid 29960 and random value 14971836
\nprocess started with pid 29961 and random value 14339677
\nprocess started with pid 29962 and random value 4460665
\nprocess started with pid 29963 and random value 12688731
\n5 processes started
\n 
\nstarted processes:
\n29245 29959 29245  1994 pts\/0    29245 S+    1000   0:00  |       _ I am number 2649735
\n29245 29960 29245  1994 pts\/0    29245 S+    1000   0:00  |       _ I am number 14971836
\n29245 29961 29245  1994 pts\/0    29245 S+    1000   0:00  |       _ I am number 14339677
\n29245 29962 29245  1994 pts\/0    29245 S+    1000   0:00  |       _ I am number 4460665
\n29245 29963 29245  1994 pts\/0    29245 S+    1000   0:00  |       _ I am number 12688731
\n 
\n# SIGUSR2:<\/strong>
\nstatus of running processes at 2019\/04\/06 16:20:53
\nshowing 2649735
\nrandom value 2649735 is used by process with pid 29959 and pgid 29245
\nshowing 14971836
\nrandom value 14971836 is used by process with pid 29960 and pgid 29245
\nshowing 14339677
\nrandom value 14339677 is used by process with pid 29961 and pgid 29245
\nshowing 4460665
\nrandom value 4460665 is used by process with pid 29962 and pgid 29245
\nshowing 12688731
\nrandom value 12688731 is used by process with pid 29963 and pgid 29245
\n5 processes found
\n 
\n# SIGTERM:<\/strong>
\nshutting down the container at 2019\/04\/06 16:21:42
\n 
\nshutting down the processes at 2019\/04\/06 16:21:42
\nstopping 2649735
\nstopping 14971836
\nstopping 14339677
\nstopping 4460665
\nstopping 12688731
\n5 processes stopped
\n<\/code>
\nIn the command terminal:
\n
\n\/bin\/kill --signal SIGUSR2 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGUSR1 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGUSR2 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGURG  $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGINT  $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGUSR2 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGPWR  $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGUSR2 $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n\/bin\/kill --signal SIGTERM $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')
\n<\/code>
\nOf course, sending the untrappable SIGKILL signal will abort the process that executes dctm.sh. However, its children processes will survive and be reparented to the root process:
\n
\n...
\nstatus of running processes at 2019\/04\/10 22:38:25
\nshowing 19996889
\nrandom value 19996889 is used by process with pid 24520 and pgid 24398
\nshowing 5022831
\nrandom value 5022831 is used by process with pid 24521 and pgid 24398
\nshowing 1363197
\nrandom value 1363197 is used by process with pid 24522 and pgid 24398
\nshowing 18185959
\nrandom value 18185959 is used by process with pid 24523 and pgid 24398
\nshowing 10996678
\nrandom value 10996678 is used by process with pid 24524 and pgid 24398
\n5 processes found
\n# \/bin\/kill --signal SIGKILL $(ps -ef | grep dctm.sh | grep -v grep | gawk '{print $2}')<\/strong>
\nKilled<\/strong>
\n 
\nps -ef | grep number | grep -v grep<\/strong>
\ndocker   24520     1  0 22:38 pts\/1    00:00:00 I am number 19996889
\ndocker   24521     1  0 22:38 pts\/1    00:00:00 I am number 5022831
\ndocker   24522     1  0 22:38 pts\/1    00:00:00 I am number 1363197
\ndocker   24523     1  0 22:38 pts\/1    00:00:00 I am number 18185959
\ndocker   24524     1  0 22:38 pts\/1    00:00:00 I am number 10996678
\n 
\n# manual killing those processes;
\nps -ef | grep number | grep -v grep | gawk '{print $2}' | xargs kill -9<\/strong>
\n 
\nps -ef | grep number | grep -v grep<\/strong>
\n<empty<\/em>>
\n 
\n# this works too:
\nkill -9 $(pgrep -f \"I am number [0-9]+$\")<\/strong>
\n# or, shorter:
\npkill -f \"I am number [0-9]+$\"<\/strong>
\n<\/code>
\nNote that there is a simpler way to kill those related processes: by using their PGID, or process group id:
\n
\nps -axj<\/strong>f | grep number | grep -v grep<\/strong>
\n    1 25248 25221<\/strong> 24997 pts\/1    24997 S     1000   0:00 I am number 3489651
\n    1 25249 25221<\/strong> 24997 pts\/1    24997 S     1000   0:00 I am number 6789321
\n    1 25250 25221<\/strong> 24997 pts\/1    24997 S     1000   0:00 I am number 15840638
\n    1 25251 25221<\/strong> 24997 pts\/1    24997 S     1000   0:00 I am number 19059205
\n    1 25252 25221<\/strong> 24997 pts\/1    24997 S     1000   0:00 I am number 12857603
\n# processes have been reparented to PPID == 1;
\n# highlighted columns 3 is the PGID;
\n# kill them using negative-PGID;
\nkill -9 -25221<\/strong>
\nps -axjf | grep number | grep -v grep<\/strong>
\n<empty<\/em>>
\n<\/code>
\nThis is why the status() commands displays the PGID.
\nIn order to tell kill that the given PID is actually a PGID, it has to be prefixed with a minus sign. Alternatively, the command:
\n
\npkill -g pgid<\/em>
\n<\/code>
\ndoes that too.
\nAll this looks quite promising so far !
\nPlease, join me now to part II of this article<\/a> for the dockerization of the test script.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ideally, but not mandatorily, the management of Documentum processes is performed at the service level, e.g. by systemd. In my blog here, I showed how to configure init files for Documentum under systemd. But containers don’t have systemd, yet. They just run processes, often only one, sometimes more if they are closely related together (e.g. […]<\/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":[197,525,42],"tags":[],"type_dbi":[],"class_list":["post-12352","post","type-post","status-publish","format-standard","hentry","category-application-integration-middleware","category-enterprise-content-management","category-operating-systems"],"acf":[],"yoast_head":"\nHow to stop Documentum processes in a docker container, and more (part I) - 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-i\/\" \/>\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 I)\" \/>\n<meta property=\"og:description\" content=\"Ideally, but not mandatorily, the management of Documentum processes is performed at the service level, e.g. by systemd. In my blog here, I showed how to configure init files for Documentum under systemd. But containers don’t have systemd, yet. They just run processes, often only one, sometimes more if they are closely related together (e.g. […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2019-04-13T10:00:41+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-10-24T07:32:15+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=\"16 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-i\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/\"},\"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 I)\",\"datePublished\":\"2019-04-13T10:00:41+00:00\",\"dateModified\":\"2025-10-24T07:32:15+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/\"},\"wordCount\":1544,\"commentCount\":0,\"articleSection\":[\"Application integration & Middleware\",\"Enterprise content management\",\"Operating systems\"],\"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-i\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/\",\"name\":\"How to stop Documentum processes in a docker container, and more (part I) - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2019-04-13T10:00:41+00:00\",\"dateModified\":\"2025-10-24T07:32:15+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-i\/#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-i\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/#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 I)\"}]},{\"@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 I) - 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-i\/","og_locale":"en_US","og_type":"article","og_title":"How to stop Documentum processes in a docker container, and more (part I)","og_description":"Ideally, but not mandatorily, the management of Documentum processes is performed at the service level, e.g. by systemd. In my blog here, I showed how to configure init files for Documentum under systemd. But containers don’t have systemd, yet. They just run processes, often only one, sometimes more if they are closely related together (e.g. […]","og_url":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/","og_site_name":"dbi Blog","article_published_time":"2019-04-13T10:00:41+00:00","article_modified_time":"2025-10-24T07:32:15+00:00","author":"Middleware Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Middleware Team","Est. reading time":"16 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-i\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/"},"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 I)","datePublished":"2019-04-13T10:00:41+00:00","dateModified":"2025-10-24T07:32:15+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/"},"wordCount":1544,"commentCount":0,"articleSection":["Application integration & Middleware","Enterprise content management","Operating systems"],"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-i\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/","url":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/","name":"How to stop Documentum processes in a docker container, and more (part I) - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2019-04-13T10:00:41+00:00","dateModified":"2025-10-24T07:32:15+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-i\/#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-i\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/how-to-stop-documentum-processes-in-a-docker-container-and-more-part-i\/#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 I)"}]},{"@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\/12352","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=12352"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12352\/revisions"}],"predecessor-version":[{"id":41187,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12352\/revisions\/41187"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=12352"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=12352"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=12352"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=12352"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}