<commit_before>dumb-init
========

[![Build Status](https://travis-ci.org/Yelp/dumb-init.svg?branch=master](https://travis-ci.org/Yelp/dumb-init) [![PyPI version](https://badge.fury.io/py/dumb-init.svg)](https://pypi.python.org/pypi/dumb-init)


`dumb-init` is a simple process designed to run as PID 1 inside Docker
containers and proxy signals to a single child process.

In Docker containers, a process typically runs as PID 1, which means that
signals like TERM will just bounce off your process unless it goes out of its
way to handle them (see the "Why" section below). This is a big problem with
scripts in languages like Python, Bash, or Ruby, and can lead to leaking Docker
containers if you're not careful.


## Why you need a signal proxy

Normally, when processes are sent a signal like `TERM`, the Linux kernel will
try to trigger any custom handlers the process has registered for that signal.

If the process hasn't registered custom handlers, the kernel will fall back to
default behavior for that signal (such as killing the process, in the case of
`TERM`).

However, processes which run as PID 1 get special treatment by the kernel, and
default signal handlers won't be applied. If your process doesn't explicitly
handle these signals, a `TERM` will have no effect at all.

For example, if you have Jenkins jobs that do `docker run my-container script`,
sending TERM to the `docker run` process will typically kill the `docker run`
command, but leave the container running in the background.<commit_msg>Fix Travis button on README<commit_after>dumb-init
========

[![Build Status](https://travis-ci.org/Yelp/dumb-init.svg?branch=master)](https://travis-ci.org/Yelp/dumb-init) [![PyPI version](https://badge.fury.io/py/dumb-init.svg)](https://pypi.python.org/pypi/dumb-init)


`dumb-init` is a simple process designed to run as PID 1 inside Docker
containers and proxy signals to a single child process.

In Docker containers, a process typically runs as PID 1, which means that
signals like TERM will just bounce off your process unless it goes out of its
way to handle them (see the "Why" section below). This is a big problem with
scripts in languages like Python, Bash, or Ruby, and can lead to leaking Docker
containers if you're not careful.


## Why you need a signal proxy

Normally, when processes are sent a signal like `TERM`, the Linux kernel will
try to trigger any custom handlers the process has registered for that signal.

If the process hasn't registered custom handlers, the kernel will fall back to
default behavior for that signal (such as killing the process, in the case of
`TERM`).

However, processes which run as PID 1 get special treatment by the kernel, and
default signal handlers won't be applied. If your process doesn't explicitly
handle these signals, a `TERM` will have no effect at all.

For example, if you have Jenkins jobs that do `docker run my-container script`,
sending TERM to the `docker run` process will typically kill the `docker run`
command, but leave the container running in the background.
{'fraction_non_alphanumeric': 0.07621851488387307, 'fraction_numerical': 0.001962708537782139, 'mean_word_length': 4.570127504553734, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 8, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2383355', 'n_tokens_mistral': 877, 'n_tokens_neox': 820, 'n_words': 443}