What is code 137 / how to gracefully shut down via SIGTERM?
Hi, I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again). I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully. What is the idiomatic way to wait on SIGTERM and close the process gracefully? Thanks, Herby
Hi, I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github. https://github.com/estebanlm/pharo-posix-signal <https://github.com/estebanlm/pharo-posix-signal> is very easy to use and it will allow you to trap any signal and do what you want ;) Esteban
On 28 Oct 2017, at 13:39, Herby VojÄÃk <herby@mailbox.sk> wrote:
Hi,
I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again).
I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully.
What is the idiomatic way to wait on SIGTERM and close the process gracefully?
Thanks, Herby
Esteban Lorenzano wrote:
Hi,
I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github.
https://github.com/estebanlm/pharo-posix-signal
is very easy to use and it will allow you to trap any signal and do what you want ;)
Thanks, looks that it'll help.
Esteban
On 28 Oct 2017, at 13:39, Herby VojÄÃk <herby@mailbox.sk <mailto:herby@mailbox.sk>> wrote:
Hi,
I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again).
I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully.
What is the idiomatic way to wait on SIGTERM and close the process gracefully?
Thanks, Herby
Esteban Lorenzano wrote:
Hi,
I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github.
Cannot load it. See attachment. Tried the on the current Pharo6.1-win. Herby
heh, I made a mistake in the README.md (fixed now) Correct install is: Metacello new repository: 'github://estebanlm/pharo-posix-signal/src'; baseline: 'POSIXSignal'; load. Esteban
On 1 Nov 2017, at 00:56, Herby VojÄÃk <herby@mailbox.sk> wrote:
Esteban Lorenzano wrote:
Hi,
I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github.
Cannot load it.
See attachment.
Tried the on the current Pharo6.1-win.
Herby <cannot-load-posixsignal.png>
Esteban Lorenzano wrote:
Hi,
I donât know if is useful in your case, but you made me remember I made a small tool to trap unix signals within Pharo. I uploaded then to github.
https://github.com/estebanlm/pharo-posix-signal
is very easy to use and it will allow you to trap any signal and do what you want ;)
Not as easy as it seems, ran this on docker image herbysk/pharo:64_61 (based on the one from that day Iceberg was backported): ======================================================================== root@2367caef3dac:/# cat s.st | trap | Iceberg enableMetacelloIntegration: true; remoteTypeSelector: #httpsUrl. Metacello new repository: 'github://estebanlm/pharo-posix-signal/src'; baseline: 'POSIXSignal'; load. trap := POSIXSignal SIGINT. trap installWith: [ :signal | 'Trapped!!' crLog ]. trap := POSIXSignal SIGTERM. trap installWith: [ :signal | 'TERM!!' crLog ]. root@2367caef3dac:/# pharo /opt/pharo/Pharo.image ${PWD}/s.st --no-quit pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END and report to the pharo mailing list whether this improves behaviour. You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux UndefinedObject>>DoIt (POSIXSignal is Undeclared) UndefinedObject>>DoIt (POSIXSignal is Undeclared) Fetched -> BaselineOfPOSIXSignal-GitHub.1509525907 --- https://github.com/estebanlm/pharo-posix-signal.git[master] --- /opt/pharo/pharo-local/iceberg/estebanlm/pharo-posi x-signal/src (Libgit) Loaded -> BaselineOfPOSIXSignal-GitHub.1509525907 --- https://github.com/estebanlm/pharo-posix-signal.git[master] --- /opt/pharo/pharo-local/iceberg/estebanlm/pharo-posix -signal/src (Libgit) Loading baseline of BaselineOfPOSIXSignal... Fetched -> POSIXSignal-GitHub.1509525907 --- https://github.com/estebanlm/pharo-posix-signal.git[master] --- /opt/pharo/pharo-local/iceberg/estebanlm/pharo-posix-signal/s rc (Libgit) Loaded -> POSIXSignal-GitHub.1509525907 --- https://github.com/estebanlm/pharo-posix-signal.git[master] --- cache ....finished baseline^C Segmentation fault Wed Nov 1 19:03:27 2017 /opt/pharo/pharo-vm/lib/pharo/5.0-201707201942/pharo Pharo VM version: 5.0-201707201942 Thu Jul 20 20:40:54 UTC 2017 gcc 4.6.3 [Production Spur 64-bit VM] Built from: CoInterpreter VMMaker.oscog-eem.2254 uuid: 4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 Revision: VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 https://github.com/OpenSma lltalk/opensmalltalk-vm.git $ Build host: Linux testing-gce-74d10329-bbfd-42e5-8995-b0e3a68c73cb 3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: /opt/pharo/pharo-vm/lib/pharo/5.0-201707201942 [default: /opt/pharo/pharo-vm/lib/pharo/5.0-201707201942/] C stack backtrace & registers: rax 0x2c1da080 rbx 0x2c1d9f10 rcx 0x2c1da138 rdx 0x2c1d9fc8 rdi 0x2c1d9ce8 rsi 0x2c1d9ce8 rbp 0x2c1d9e58 rsp 0x2c1da1f0 r8 0x2c1d9728 r9 0x2c1d97e0 r10 0x2c1d9898 r11 0x2c1d9950 r12 0x2c1d9a08 r13 0x2c1d9ac0 r14 0x2c1d9b78 r15 0x2c1d9c30 rip 0x2c1da2a8 *[0x7ffc2c1da2a8] /opt/pharo/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x41ccd1] /opt/pharo/pharo-vm/lib/pharo/5.0-201707201942/pharo[0x41d05f] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f155abba390] [0x7f155b151000] [0x0] Smalltalk stack dump: 0x7ffc2c1de400 M ProcessorScheduler class>idleProcess 0x2f982d8: a(n) ProcessorScheduler class 0x7ffc2c1de440 I [] in ProcessorScheduler class>startUp 0x2f982d8: a(n) ProcessorScheduler class 0x7ffc2c1de480 I [] in BlockClosure>newProcess 0x60396e8: a(n) BlockClosure Most recent primitives relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock signal primSignal:atUTCMicroseconds: wait millisecondClockValue millisecondClockValue tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: millisecondClockValue yield millisecondClockValue signal primUTCMicrosecondsClock primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock signal primSignal:atUTCMicroseconds: wait millisecondClockValue millisecondClockValue tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: millisecondClockValue yield millisecondClockValue signal primUTCMicrosecondsClock primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock signal primSignal:atUTCMicroseconds: wait millisecondClockValue millisecondClockValue tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: millisecondClockValue yield millisecondClockValue signal primUTCMicrosecondsClock primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock signal primSignal:atUTCMicroseconds: wait millisecondClockValue millisecondClockValue tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: millisecondClockValue yield millisecondClockValue signal primUTCMicrosecondsClock primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: primUTCMicrosecondsClock signal primSignal:atUTCMicroseconds: wait millisecondClockValue millisecondClockValue tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: tempAt: tempAt:put: tempAt: terminateTo: findNextUnwindContextUpTo: terminateTo: millisecondClockValue yield millisecondClockValue signal primUTCMicrosecondsClock primSignal:atUTCMicroseconds: wait wait relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: stack page bytes 8192 available headroom 5576 minimum unused headroom 6000 (Segmentation fault) /usr/local/bin/pharo: line 11: 175 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" root@2367caef3dac:/# ==================================== Same result in 32bit :-( Herby
Hi Herby, eventually you might want to look at https://github.com/moby/moby/issues/1063 but then i dont know anything about these things. werner On 10/28/2017 01:39 PM, Herby VojÄÃk wrote:
Hi,
I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again).
I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully.
What is the idiomatic way to wait on SIGTERM and close the process gracefully?
Thanks, Herby
werner kassens wrote:
Hi Herby, eventually you might want to look at https://github.com/moby/moby/issues/1063 but then i dont know anything about these things.
Hopefully they have this solved already... but I learned 137 means "killed". generally; did not know. :-)
werner
Herby
On Sat, Oct 28, 2017 at 01:39:56PM +0200, Herby Voj????k wrote:
Hi,
I had to find out how to automatically deploy the backend written in Pharo, and so far it uses docker-compose stop to stop the instance (and later docker-compose up -d to get everything up again).
I noticed the stop phase takes a while and ends with status code 137. I presume it ended forcefully and not gracefully.
What is the idiomatic way to wait on SIGTERM and close the process gracefully?
Thanks, Herby
Try this: mySemaphore := OSProcess accessor forwardSigTerm. mySemaphore wait. "wait eg in a process until SIGTERM is detected" Typically you would use #forwardSigTerm to set up the signal handler, then start a Smalltalk process that waits on the semaphore and does whatever you want to do when the Unix signal is detected. You can do signal forwarding for any Unix signal, the #forwardSigTerm is just a convenience method. Dave
participants (4)
-
David T. Lewis -
Esteban Lorenzano -
Herby VojÄÃk -
werner kassens