pid1: Do signal handling and orphan reaping for Unix PID1 init processes

[ library, mit, program, system ] [ Propose Tags ]

Please see README.md or view Haddocks at https://www.stackage.org/package/pid1


[Skip to Readme]

Modules

[Index] [Quick Jump]

Flags

Manual Flags

NameDescriptionDefault
static

Statically link executables.

Disabled

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0, 0.1.0.1, 0.1.1.0, 0.1.2.0, 0.1.3.0, 0.1.3.1
Change log ChangeLog.md
Dependencies base (>=4 && <5), directory, pid1, process (>=1.2), unix [details]
License MIT
Copyright 2016 Michael Snoyman
Author Michael Snoyman
Maintainer michael@snoyman.com
Category System
Home page https://github.com/fpco/pid1#readme
Source repo head: git clone https://github.com/fpco/pid1
Uploaded by psibi at 2022-11-29T08:32:36Z
Distributions Arch:0.1.3.1, Debian:0.1.2.0, LTSHaskell:0.1.3.1, NixOS:0.1.3.1, Stackage:0.1.3.1
Reverse Dependencies 1 direct, 4 indirect [details]
Executables pid1
Downloads 8037 total (32 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2022-11-29 [all 1 reports]

Readme for pid1-0.1.3.1

[back to package description]

pid1

Build

Do signal handling and orphan reaping for Unix PID1 init processes.

This provides a Haskell library, and an executable based on that library, for initializing signal handlers, spawning and child process, and reaping orphan processes. These are the responsibilities that must be fulfilled by the initial process in a Unix system, and in particular comes up when running Docker containers.

This library/executable will automatically detect if it is run as some process besides PID1 and, if so, use a straightforward exec system call instead.

NOTE This package is decidedly not portable, and will not work on Windows. If you have a use case where you think it makes sense to run on Windows, I'd be interested in hearing about it.

For a discussion on why this is useful, see this repo.

Usage

pid1 [-e|--env ENV] [-u|--user USER] [-g|--group GROUP] [-w|--workdir DIR] [-t|--timeout TIMEOUT] COMMAND [ARG1 ARG2 ... ARGN]

Where:

  • -e, --env ENV - Override environment variable from given name=value pair. Can be specified multiple times to set multiple environment variables.
  • -u, --user USER - The username the process will setuid before executing COMMAND
  • -g, --group GROUP - The group name the process will setgid before executing COMMAND
  • -w, --workdir DIR - chdir to DIR before executing COMMAND
  • -t, --timeout TIMEOUT - timeout (in seconds) to wait for all child processes to exit (Default is 5 seconds)

WARNING: by default pid1 will first send the TERM signal to it's "immediate child" process. In most scenarios that will be the only process running but in some cases that will be the "main" process that could have spawned it's own children. In this scenario it's prudent to shutdown the "main" process first, since usually it has mechanisms in place to shut down it's children. If we were to shutdown a child process before "main" was shutdown it might try to restart it. This is why, if the "main" process doesn't exit within timeout we will proceed to send the TERM signal to all processes and wait again for timeout until we finally send the KILL signal to all processes. This is a breaking change since 0.1.3.0.

The recommended use case for this executable is to embed it in a Docker image. Assuming you've placed it at /sbin/pid1, the two commonly recommended usages are:

  1. Override the entrypoint, either via ENTRYPOINT in your Dockerfile or --entrypoint on the command line.

    docker run --rm --entrypoint /sbin/pid1 fpco/pid1 ps
    
  2. Add /sbin/pid1 to the beginning of your command.

    docker run --rm --entrypoint /usr/bin/env fpco/pid1 /sbin/pid1 ps
    

Docker images

You can find various docker images here. We usually target Ubuntu LTS as the parent image.