Why with some docker images, CTRL+C doesn't kill the "docker run" command?

Question

With this image (the Caddy webserver):

docker run --rm -p 80:80 caddy:latest 

I can stop it with sending CTRL+C within the terminal.

Some other images won't work this way, for example MariaDB:

docker run -it --rm -p 3306:3306 -e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=true mariadb:latest

I'm not able to stop it with CTRL+C

I've noticed that in Caddy Dockerfile there is no ENTRYPOINT but only CMD, whereas MariaDB has both an ENTRYPOINT and a CMD.

Why? Is there any reason NOT to support the handling of a kill signal? How can one support the SIGTERM in a docker entrypoint, if that is the reason?

Answer 1

MariaDB ignores SIGINT by masking its delivery to the process using sigprocmask.

This was done a long time ago on some assumptions maybe around accidental triggering on shutdown when started in a terminal. There might be a case in old-school sysv scripts where a closed terminal quickly after service mariadb start may have delivered a SIGINT to mariadbd (unverified). I can't see any requests to remove the SIGINT masking.

In the container the entrypoint script execs the mariadbd server executable after a basic setup, so the behaviour of ignoring SIGINT is what was historically there rather than an explicit decision.

The --gdb option on the command line (for server or container) will prevent the ignoring of SIGINT and achieve the result of being about to SIGINT to terminate MariaDB safely. It can also be provided in a .cnf file.

example:

$  podman run --env MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=1 --rm mariadb:10.6 --gdb

.
2023-06-18 22:42:49 0 [Note] mariadbd: ready for connections.
Version: '10.6.14-MariaDB-1:10.6.14+maria~ubu2004'  socket: '/run/mysqld/mysqld.sock'  port: 0  mariadb.org binary distribution

explicit SIGINT, though ctrl-C on command line also works.

$ podman kill --signal SIGINT mariadbsiginttest 
mariadbsiginttest

2023-06-18 22:44:31 0 [Note] mariadbd (initiated by: unknown): Normal shutdown
2023-06-18 22:44:31 0 [Note] InnoDB: FTS optimize thread exiting.
2023-06-18 22:44:31 0 [Note] InnoDB: Starting shutdown...
2023-06-18 22:44:31 0 [Note] InnoDB: Dumping buffer pool(s) to /var/lib/mysql/ib_buffer_pool
2023-06-18 22:44:31 0 [Note] InnoDB: Buffer pool(s) dump completed at 230618 22:44:31
2023-06-18 22:44:31 0 [Note] InnoDB: Removed temporary tablespace data file: "./ibtmp1"
2023-06-18 22:44:31 0 [Note] InnoDB: Shutdown completed; log sequence number 42294; transaction id 15
2023-06-18 22:44:31 0 [Note] mariadbd: Shutdown complete

MariaDB can handle termination at any point, including SIGKILL (cannot be caught except by an init process) or power failures. This is part of the durability (the D in ACID) for transactional databases. Upon restart uncommitted transactions are cleaned up. Doing a graceful termination does mean the startup doesn't need a crash recovery and its quicker however.