Skip to content
This repository was archived by the owner on Feb 24, 2023. It is now read-only.

Commit 7d2b14f

Browse files
Merge pull request #8 from apatil/detach-docs
Added section to README about detaching client
2 parents 26ae3a0 + a457e68 commit 7d2b14f

1 file changed

Lines changed: 6 additions & 1 deletion

File tree

README.md

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ In short, it's best to always have `--name %n --rm` in your unit file's `ExecSta
4949

5050
The best way I've found to run containers under systemd is to always assign the container a name. Even better is to put `--name %n` in your unit file and then the name of the container will match the name of the service unit.
5151

52-
If you don't name your container, you will essentially be creating a new container on every start that will get orphaned. You're probably clever and thinking you can just add `--rm` and that will take care of the orphans. The problem with this is that `--rm` is not super reliable. By naming your container, `systemd-docker` will take extra care to keep the systemd unit and the container in sync. For example, if you do `--name %n --rm`, `systemd-docker` will ensure that the container is really deleted each time. The issue with `--rm` is that the remove is done from the client side. If the client dies, the container is not deleted.
52+
If you don't name your container, you will essentially be creating a new container on every start that will get orphaned. You're probably clever and thinking you can just add `--rm` and that will take care of the orphans. The problem with this is that `--rm` is not super reliable. By naming your container, `systemd-docker` will take extra care to keep the systemd unit and the container in sync. For example, if you do `--name %n --rm`, `systemd-docker` will ensure that the container is really deleted each time. The issue with `--rm` is that the remove is done from the client side. If the client dies, the container is not deleted.
5353

5454
If you do `--name %n --rm`, `systemd-docker` on start will look for the named container. If it exists and is stopped, it will be deleted. This is really important if you ever change your unit file. If you change your `ExecStart` command, and it is a named container, the old values will be saved in the stopped container. By ensuring the container is always deleted, you ensure the args in `ExecStart` are always in sync.
5555

@@ -100,6 +100,11 @@ By default `systemd-docker` will send READY=1 to the systemd notification socket
100100

101101
What this will do is set up a bind mount for the notification socket and then set the NOTIFY_SOCKET environment variable. If you are going to use this feature of systemd, take some time to understand the quirks of it. More info in this [mailing list thread](http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/18649). In short, systemd-notify is not reliable because often the child dies before systemd has time to determine which cgroup it is a member of
102102

103+
Detaching the client
104+
====================
105+
106+
The `-d` argument to docker has no effect under `systemd-docker`. To cause the `systemd-docker` client to detach after the container is running, simply use `--logs=false --rm=false`. If either `--logs` or `--rm` is true, the `systemd-docker` client will stay alive until it is killed or the container exits.
107+
103108
Running on CoreOS
104109
=================
105110

0 commit comments

Comments
 (0)