Docker Container: Uncaught Kill Signal

Manish Demblani — Wed, 08 Aug 2018 14:54:32 +0000

Has it ever happened, that you are unable to terminate/stop a running Docker container instance. Trying to press the Ctrl+C (Cmd+C) in your terminal multiple times, but being hapless all the time.

Ultimately you resort to killing the Docker process and in this way, resulting in your container stopping successfully with the famous exit code 0(if you are lucky) or it getting killed forcefully with an exit error.

In-case an exit error occurs due to killing the container, it results in corruption of the data in the volume associated with that container and hence, you have to re-build your containers.

There are two reasons due to which this happens:

The container does not listen to the kill signals such as SIGINT that is generated by Ctrl+C (Cmd+C) key combination
The container shutdown process exceeds the timeout time specified by the docker process which it allots a container to shutdown, resulting in the docker process forcibly killing the container and hence the corruption.

Solution

Now there are two known ways to solve the above stated problem:

Increase the Timeout
Patch the Entry Script

Increase the Timeout

In this case, you simply inform the docker process to wait for some more time until the container performs a graceful shutdown. The value be which the timeout should be increased, should be a little more than the time the container takes to shutdown after detecting the signal. To get started, you can set the timeout to around 30 seconds as a safe-bet.

docker stop -t 30 CONTAINER_NAME

Patch the Entry Script

In this method, we basically monkey-patch the entry file of the container with custom code, that allows us to detect the SIGINT signal sent to the container.

To patch the entry script, we will have to create a listener file(signal-listener.sh):


#!/bin/bash
# A wrapper around /entrypoint.sh to trap the SIGINT signal (Ctrl+C) and forwards it to the mysql daemon
# In other words : traps SIGINT and SIGTERM signals and forwards them to the child process as SIGTERM signals

signalListener() {
    "$@" &
    pid="$!"
    trap "echo 'Stopping PID $pid'; kill -SIGTERM $pid" SIGINT SIGTERM

    # A signal emitted while waiting will make the wait command return code > 128
    # Let's wrap it in a loop that doesn't end before the process is indeed stopped
    while kill -0 $pid > /dev/null 2>&1; do
        wait
    done
}

signalListener /entrypoint.sh $@

Make sure the file is in the same folder as the Dockerfile you will build.

The next step, is to wrap the entrypoint.sh file with the signal-listener.sh file. In your Dockerfile add the following lines at the very end:


COPY signal-listener.sh /run.sh

# Entrypoint overload to catch the ctrl+c and stop signals
ENTRYPOINT ["/bin/bash", "/run.sh"]
CMD [ADD_THE_DEFAULT_DOCKER_CMD_IF_ANY]

Now if you observe, after running the docker container, you could press the Ctrl+C(Cmd+C) combination and pass it the SIGINT command. This command would now be detected by the container and it would terminate gracefully.

Credits:

This post is based on the solution provided in the following Github issue: Container does not catch signals and exit (Ctrl+C). Thanks to user Jérémy VIGNELLES for the solution provided.

Breaking out from the MySQL character-set hell

Manish Demblani — Sat, 10 Mar 2018 16:49:25 +0000

The MySQL charset hell, a dangerous place to be in. Read to know how you fall in it, what to do if you find yourself in it and how to migrate from latin1 to utf8mb4.

If you ever encountered databases and SQL (or tried to know what they are), you must’ve have stumbled upon MySQL (An open source relational database management system (RDBMS) based on Structured Query Language (SQL)). In MySQL, have you ever wondered what Character-Set and Collation mean?

Has it ever occurred, that while querying for data in your database (using any MySQL GUI or CLI) you see gobbledygook(garbled data)? For eg. You enter the following text in your application:

English to Arabic….الإنجليزية إلى العربية

but on querying for the same data in your database table you see:

Note: Although this article focuses on the fact on how to move your database from latin1 to utf8mb4, you can follow this article to move between any two character-sets and collation.

. . .

Emergence and Rise of UTF-8

Those who know how computer encoding works would know that for a long period of time, ASCII (American Standard Code for Information Interchange) was the default encoding standard. The 8-bit/1 byte character encoding covered all the characters in the English Language, Numbers and the most commonly used special characters (!,.* and so on…). But with time, many Non-English speakers also started using computers and eventually computers started supporting these foreign languages.

So as to support these foreign languages, a good byte stream encoding system was required, which would support a wide-range of characters (English and foreign languages), since the ASCII encoding was just 1-byte and was already filled up from 0–255 (To see a list of supporting characters), a new multi-byte character set system was required. The search for a new system started in 1992 and in that year, UTF-1 was introduced, but due to its incompetence led to the development of UTF-8 in January 1993.

"When I set out to create MOS 865, do you think it just happened overnight? No. There was MOS 1, that burnt down my Dad’s garage. There was MOS 2 that would only schedule appointments in January. And 862 others that I learned from…": Pete Becker (Friends)

UTF-8 (a.k.a. Unicode) quickly rose to prominence and major computer systems started adopting it mainly due to its backward compatibility with the existing ASCII system. In 2008, Google reported that Unicode became the most common encoding for HTML files.

If you want to know more about what Character-Sets and encoding mean and how they work and help in Computers understand languages and Software Developers develop international software, then read what Joel Spolsky has to say in his blog The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

. . .

This post was originally published on my blog here. The reminder of this article covers the following topics:

MySQL — Collation and Character Set
Latin1 and MySQL
MySQL Character-Set Hell — Reproducing The Problem
Fixing The Problem
Nth Encoded Characters
Application Precautions

DEV Community: Manish Demblani

Docker Container: Uncaught Kill Signal

Solution

Increase the Timeout

Patch the Entry Script

Credits:

This post is based on the solution provided in the following Github issue: Container does not catch signals and exit (Ctrl+C). Thanks to user Jérémy VIGNELLES for the solution provided.

Breaking out from the MySQL character-set hell

The MySQL charset hell, a dangerous place to be in. Read to know how you fall in it, what to do if you find yourself in it and how to migrate from latin1 to utf8mb4.

. . .

Emergence and Rise of UTF-8

. . .

This post was originally published on my blog here. The reminder of this article covers the following topics: