Propose better way to run docker from a unit file #6791

Open
ibuildthecloud opened this Issue Jul 1, 2014 · 29 comments

Comments

Projects
None yet
@ibuildthecloud
Contributor

ibuildthecloud commented Jul 1, 2014

Systemd does a lot of stuff. Docker does a lot of stuff. That stuff may or may not overlap. I don't really care. I just need to solve one very specific problem. I just need a sane way to launch Docker containers in a systemd environment as a system service. As it stands today, the only way I know how is to do docker start -a or docker run ... without -d. Then dockerd launches the container in the background and systemd essentially monitors the docker client. Two problems with this. First, whether or not the docker client is running says very little about whether the actual container is running. Second, I'm left with a rather large docker run process in memory that's not providing much value except to stream stdout/stderr to journald.

So I hacked up the below script to make things better, or really just to see if it was possible to make things better since the script is just a dirty hack. You don't really need to read the script, just skip down and I'll explain what it does.

#!/bin/bash
set -e

ID=$(/usr/bin/docker "$@")
PID=$(docker inspect -f '{{.State.Pid}}' $ID)

declare -A SRC DEST

for line in $(grep slice /proc/$PID/cgroup); do
        IFS=: read _ NAME LOC <<< "$line"
        SRC[${NAME##name=}]=$LOC
done 

for line in $(grep slice /proc/$$/cgroup); do
        IFS=: read _ NAME LOC <<< "$line"
        DEST[${NAME##name=}]=$LOC
done

for type in ${!SRC[@]}; do
        from=/sys/fs/cgroup/${type}${SRC[$type]}
        to=/sys/fs/cgroup/$type/"${DEST[$type]}"/$(basename "${SRC[$type]}")

        echo $from "=>" $to
        mkdir -p $to
        for p in $(<$from/cgroup.procs); do
                echo $p > $to/cgroup.procs
        done
done

echo $PID > /var/run/test.pid

Then I wrote the following unit file

[Unit]
Description=My Service
After=docker.service
Requires=docker.service

[Service]
ExecStart=/opt/bin/docker-wrapper.sh run -d busybox /bin/sh -c "while true; do echo Hello World; sleep 1; done"
Type=forking
PIDFile=/var/run/test.pid

[Install]
WantedBy=multi-user.target

So what this does (and I know it's a hack, but I wanted to see if my proposal has any chance of working) is that after the container is launched, I look up the PID of the container and all of its cgroups. I then create child cgroups of the systemd cgroups and then move the PIDs from the original cgroups to the systemd child cgroups. After that is done I then write the PID of the container to a file. I end up with systemd cgroups being the parent, then a child cgroup under that. Looking something like below

  ├─test.service
  │ └─docker-8a0ff7503e0fca4f44d48f76a24cbcae82079818e3ad4d0d707ccf5765698184.scope
  │   ├─19103 /bin/sh -c while true; do echo Hello World; sleep 1; done
  │   └─19169 sleep 1

Also, since I told systemd to use a PIDFile, systemd is monitoring the PID 1 of the container because I wrote it to a file. So now if I do either docker stop or systemctl stop things just work (at least they seem to do) and I don't have a useless docker client hanging around in memory Now if you look at the script, you'll notice I'm just moving the PIDs, not the settings, so yeah, total hack that defeats the purpose of the original cgroup, but that's not the point right now.

Here's what I propose to make systemd and docker integration a tad bit better. When you want to run docker in a systemd unit you run docker run/start --yo-dawg-use-my-cgroups-as-your-parent ... which will read the current /proc/$$/cgroup of the client and pass it to dockerd. Dockerd now just creates its cgroups as a child of the cgroups passed in, if the subsystem exists. I think this means we can remove the systemd cgroup code and just use the cgroup fs based code (but docker will still have to write to the name=systemd fs). So now systemd can setup the parent cgroups however it wishes and Docker can setup the child cgroups how ever it wishes.

Is this the best solution? Probably not. But it seems a lot better than what we have today and it solves a current pain point.

Is this just plain stupid or already been thought of and shot down?

@ibuildthecloud ibuildthecloud changed the title from Slightly better systemd integration to Propose better way to run docker from a unit file Jul 2, 2014

@vbatts

This comment has been minimized.

Show comment
Hide comment
@vbatts

vbatts Jul 11, 2014

Contributor

From the [significant]discussion around systemd unit files in the contributor meeting yesterday https://botbot.me/freenode/docker-dev/msg/17771621/). The example unit files is @crosbymichael https://github.com/crosbymichael/.dotfiles/blob/master/systemd/redis.service

Contributor

vbatts commented Jul 11, 2014

From the [significant]discussion around systemd unit files in the contributor meeting yesterday https://botbot.me/freenode/docker-dev/msg/17771621/). The example unit files is @crosbymichael https://github.com/crosbymichael/.dotfiles/blob/master/systemd/redis.service

@wallrj wallrj referenced this issue in ClusterHQ/flocker Aug 26, 2014

Closed

Replace geard/systemd interaction/dependency with direct Docker usage #608

4 of 9 tasks complete
@ibuildthecloud

This comment has been minimized.

Show comment
Hide comment
@ibuildthecloud

ibuildthecloud Oct 14, 2014

Contributor

FYI, for anybody who stumbles upon this issue. I created https://github.com/ibuildthecloud/systemd-docker as an attempt to address the issues between docker and systemd.

Contributor

ibuildthecloud commented Oct 14, 2014

FYI, for anybody who stumbles upon this issue. I created https://github.com/ibuildthecloud/systemd-docker as an attempt to address the issues between docker and systemd.

@pikeas

This comment has been minimized.

Show comment
Hide comment
@pikeas

pikeas Jan 6, 2015

Any new thoughts/movement on this?

pikeas commented Jan 6, 2015

Any new thoughts/movement on this?

@tbatchelli

This comment has been minimized.

Show comment
Hide comment
@tbatchelli

tbatchelli Jan 22, 2015

I have been using @ibuildthecloud's systemd-docker and the combo is a killer. Would be better if the issues it addresses issues were dealt with by docker itself

I have been using @ibuildthecloud's systemd-docker and the combo is a killer. Would be better if the issues it addresses issues were dealt with by docker itself

@larsks

This comment has been minimized.

Show comment
Hide comment
@larsks

larsks Jan 29, 2015

Contributor

This issue is hardly specific to systemd. It affects any environment in which someone wants to reliably start and monitor a container, which would include just about any non-SysV init system (systemd, upstart, runit, daemontools, launchd).

Contributor

larsks commented Jan 29, 2015

This issue is hardly specific to systemd. It affects any environment in which someone wants to reliably start and monitor a container, which would include just about any non-SysV init system (systemd, upstart, runit, daemontools, launchd).

@ibukanov

This comment has been minimized.

Show comment
Hide comment
@ibukanov

ibukanov Jan 31, 2015

A simpler solution then using @ibuildthecloud's systemd-docker is to start a docker container in the background in ExecStartPre via run -d container or start container and then using ExecStart=/usr/bin/docker logs -f container. This way systemd, before starting any dependent units, waits until docker run -d or docker start returns and that happens only when the container is started. Then the logs command sends the initial startup logs to systemd and journal and then continue to do so as the new logs arrive until the container stops.

With this approach one also needs to put -/usr/bin/docker stop container both to ExecStop and ExecStopPost. The latter ensures that if /usr/bin/docker logs dies before the container terminates, then systemd still stops the container. Note that by just using ExecStopPost without ExecStop one will not get the termination logs into the journal as systemctl stop will kill the logs command before ExecStopPost stops the container.

A simpler solution then using @ibuildthecloud's systemd-docker is to start a docker container in the background in ExecStartPre via run -d container or start container and then using ExecStart=/usr/bin/docker logs -f container. This way systemd, before starting any dependent units, waits until docker run -d or docker start returns and that happens only when the container is started. Then the logs command sends the initial startup logs to systemd and journal and then continue to do so as the new logs arrive until the container stops.

With this approach one also needs to put -/usr/bin/docker stop container both to ExecStop and ExecStopPost. The latter ensures that if /usr/bin/docker logs dies before the container terminates, then systemd still stops the container. Note that by just using ExecStopPost without ExecStop one will not get the termination logs into the journal as systemctl stop will kill the logs command before ExecStopPost stops the container.

@stuartpb

This comment has been minimized.

Show comment
Hide comment

stuartpb commented Jun 8, 2015

as noted by ibuildthecloud/systemd-docker#25, #10427 helps with this

@geekpete

This comment has been minimized.

Show comment
Hide comment
@geekpete

geekpete Oct 7, 2015

Not that it's going to be an init system into the future, but using Upstart worked quite well for controlling docker containers for the most part in a simple config file per service that did everything you'd want.

geekpete commented Oct 7, 2015

Not that it's going to be an init system into the future, but using Upstart worked quite well for controlling docker containers for the most part in a simple config file per service that did everything you'd want.

hrldcpr added a commit to heatseeknyc/relay that referenced this issue Nov 6, 2015

use `docker run -d` in systemd units so that they're not considered s…
…tarted until the container is actually running, otherwise dependent services may try to start too soon 😭 - see moby/moby#6791 (comment)

ginkel added a commit to tgbyte/puppet-docker that referenced this issue Dec 22, 2015

colszowka added a commit to experimental-platform/platform-configure that referenced this issue Mar 9, 2016

@wallies wallies referenced this issue in Capgemini/Apollo Apr 18, 2016

Open

better way to run docker from a unit file #699

@ketzacoatl ketzacoatl referenced this issue in hashicorp/nomad Apr 19, 2016

Closed

Add volumes for docker driver #62

@ketzacoatl ketzacoatl referenced this issue in hashicorp/nomad May 24, 2016

Open

Persistent data on nodes #150

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Sep 16, 2016

Contributor

It's still an issue if I understand correctly.

Contributor

LK4D4 commented Sep 16, 2016

It's still an issue if I understand correctly.

@berglh

This comment has been minimized.

Show comment
Hide comment
@berglh

berglh Feb 4, 2017

Now that dockerd can be restarted with the --live-restore directive, if you have started containers with systemd, the docker client stops because the daemon is no longer available when restarting dockerd.

Even in @ibukanov example above, if the docker daemon restarts, the docker client will fail to connect to the daemon to get the logs and will cause the systemd unit to fail. Sure it might restart, but my goal is to have the container to continue running while being managed by systemd. Yes, the unit should require the docker daemon for startup, but once it's running, I want systemd to track the pid of the process launched by the container.

If I have the Restart=no directive set, the container will still run, logging of the docker client to journalctl will stop and the systemd unit will be in a failed state. If the unit file is set to Restart=on-failure, then the unit file will restart and either fail to start, because the container is already running or you force stop/rm old containers to prevent start-up problems using ExecStartPre=-/usr/bin/docker rm -f container.

This problem with systemd effectively stops you from making any decent use of the --live-restore option when managing the containers with unit files. I've tried looking at --cgroup-parent and using the systemd cgroup driver, but I am yet to see how this solves my problem. Sure systemd is aware of the cgroup, but it's not tracking the pid of the container, but the pid of the docker client that was used to launch the container.

I am unsure of my understanding in general around this behaviour, and there may be some example of structuring ExecStartPre, ExecStart, ExecStop and ExecStopPost to get the desired result. I'm going to read through @ibuildthecloud 's solution to this and see if I can come up with something less convoluted, but as far as I can see the issue still stands.

berglh commented Feb 4, 2017

Now that dockerd can be restarted with the --live-restore directive, if you have started containers with systemd, the docker client stops because the daemon is no longer available when restarting dockerd.

Even in @ibukanov example above, if the docker daemon restarts, the docker client will fail to connect to the daemon to get the logs and will cause the systemd unit to fail. Sure it might restart, but my goal is to have the container to continue running while being managed by systemd. Yes, the unit should require the docker daemon for startup, but once it's running, I want systemd to track the pid of the process launched by the container.

If I have the Restart=no directive set, the container will still run, logging of the docker client to journalctl will stop and the systemd unit will be in a failed state. If the unit file is set to Restart=on-failure, then the unit file will restart and either fail to start, because the container is already running or you force stop/rm old containers to prevent start-up problems using ExecStartPre=-/usr/bin/docker rm -f container.

This problem with systemd effectively stops you from making any decent use of the --live-restore option when managing the containers with unit files. I've tried looking at --cgroup-parent and using the systemd cgroup driver, but I am yet to see how this solves my problem. Sure systemd is aware of the cgroup, but it's not tracking the pid of the container, but the pid of the docker client that was used to launch the container.

I am unsure of my understanding in general around this behaviour, and there may be some example of structuring ExecStartPre, ExecStart, ExecStop and ExecStopPost to get the desired result. I'm going to read through @ibuildthecloud 's solution to this and see if I can come up with something less convoluted, but as far as I can see the issue still stands.

@ibukanov

This comment has been minimized.

Show comment
Hide comment
@ibukanov

ibukanov Feb 4, 2017

@berglh At this point I long gave up to trying to integrate docker with systemd. It just does not work due to very different approaches. So with docker I stick with its native commands using no unit files. In practice any dependency problems between containers can be solved with a shell script running in container that just waits until the condition is meat before starting the main application. Surprisingly this makes the whole setup much more robust and I have no problems with docker daemon restarts as it nicely restarts all my containers.

If systemd intgeration and unit files is a must, consider using runc, not docker itself, to run docker containers.

ibukanov commented Feb 4, 2017

@berglh At this point I long gave up to trying to integrate docker with systemd. It just does not work due to very different approaches. So with docker I stick with its native commands using no unit files. In practice any dependency problems between containers can be solved with a shell script running in container that just waits until the condition is meat before starting the main application. Surprisingly this makes the whole setup much more robust and I have no problems with docker daemon restarts as it nicely restarts all my containers.

If systemd intgeration and unit files is a must, consider using runc, not docker itself, to run docker containers.

@berglh

This comment has been minimized.

Show comment
Hide comment
@berglh

berglh Feb 10, 2017

@ibukanov I'll checkout runc for sure, but I'm currently using fleet and etcd on Oracle Enterprise Linux. Considering fleet is going to be officially not supported by CoreOS anymore, maybe I'm better off moving to Kubernetes or Openshift. The thing is that fleet is such a simple and straight forward concept of scheduling unit files, it's been attractive for the particular cluster I'm managing. Regardless, I'm going to have to probably move from fleet in the long run.

berglh commented Feb 10, 2017

@ibukanov I'll checkout runc for sure, but I'm currently using fleet and etcd on Oracle Enterprise Linux. Considering fleet is going to be officially not supported by CoreOS anymore, maybe I'm better off moving to Kubernetes or Openshift. The thing is that fleet is such a simple and straight forward concept of scheduling unit files, it's been attractive for the particular cluster I'm managing. Regardless, I'm going to have to probably move from fleet in the long run.

@dashesy

This comment has been minimized.

Show comment
Hide comment
@dashesy

dashesy Jun 22, 2017

@ibukanov rkt can run docker images as-is, and works well with systemd.

dashesy commented Jun 22, 2017

@ibukanov rkt can run docker images as-is, and works well with systemd.

Mortal added a commit to Mortal/csaudk-domserver that referenced this issue Aug 11, 2017

Mortal added a commit to Mortal/csaudk-domserver that referenced this issue Aug 11, 2017

@mathstuf

This comment has been minimized.

Show comment
Hide comment
@mathstuf

mathstuf Oct 24, 2017

Note that rkt currently requires that images be pushed to a registry, so running local images isn't going to work out of the box. See rkt/rkt#2392.

Note that rkt currently requires that images be pushed to a registry, so running local images isn't going to work out of the box. See rkt/rkt#2392.

@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 18, 2018

It's April 2018. Is there any best practice to start containerized services with systemd?

If not, what again are the benefits of starting docker container as:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

instead of

-ExecStart=/usr/bin/docker run --name container1 some-image 

?

It's April 2018. Is there any best practice to start containerized services with systemd?

If not, what again are the benefits of starting docker container as:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

instead of

-ExecStart=/usr/bin/docker run --name container1 some-image 

?

@dashesy

This comment has been minimized.

Show comment
Hide comment
@dashesy

dashesy Apr 18, 2018

@aholbreich the best way is to use rkt, sorry but docker does not play well with systemd. Unfortunately rkt is not popular.

dashesy commented Apr 18, 2018

@aholbreich the best way is to use rkt, sorry but docker does not play well with systemd. Unfortunately rkt is not popular.

@mwpastore

This comment has been minimized.

Show comment
Hide comment
@mwpastore

mwpastore Apr 18, 2018

@aholbreich The former works well with SystemD; the latter does not. In order to use a docker run command as your ExecStart=, you have to use a wrapper like ibuildthecloud/systemd-docker. Either way, if you use SystemD, you can't use --live-restore as @berglh documented above.

mwpastore commented Apr 18, 2018

@aholbreich The former works well with SystemD; the latter does not. In order to use a docker run command as your ExecStart=, you have to use a wrapper like ibuildthecloud/systemd-docker. Either way, if you use SystemD, you can't use --live-restore as @berglh documented above.

@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 19, 2018

@mwpastore Ok, i understand wrapper and the --live-restore.
"The former works well with SystemD; the latter does not. " can you elaborate on that...
If i see it correctly this:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

is also not a real enabler of --live-restore, or? So any advantage here in these lines?

@dashesy i will consider rkt some day, but this out of scope now (for many reasons)

@mwpastore Ok, i understand wrapper and the --live-restore.
"The former works well with SystemD; the latter does not. " can you elaborate on that...
If i see it correctly this:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

is also not a real enabler of --live-restore, or? So any advantage here in these lines?

@dashesy i will consider rkt some day, but this out of scope now (for many reasons)

@mwpastore

This comment has been minimized.

Show comment
Hide comment
@mwpastore

mwpastore Apr 19, 2018

@aholbreich This works with SystemD, but does not enable --live-restore:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

This does not work with SystemD; you need a wrapper, and even with a wrapper, it does not enable --live-restore:

ExecStart=/usr/bin/docker run --name container1 some-image 

mwpastore commented Apr 19, 2018

@aholbreich This works with SystemD, but does not enable --live-restore:

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

This does not work with SystemD; you need a wrapper, and even with a wrapper, it does not enable --live-restore:

ExecStart=/usr/bin/docker run --name container1 some-image 
@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 19, 2018

This does not work with SystemD

Of course it works:
ExecStart=/usr/bin/docker run --name container1 some-image

This does not work with SystemD

Of course it works:
ExecStart=/usr/bin/docker run --name container1 some-image

@mwpastore

This comment has been minimized.

Show comment
Hide comment
@mwpastore

mwpastore Apr 19, 2018

@aholbreich

Of course it works:

Please re-read the details of this issue and ibuildthecloud/systemd-docker#readme, and you will clearly see that—while SystemD does launch the process using that syntax—there's much more to it than that.

@aholbreich

Of course it works:

Please re-read the details of this issue and ibuildthecloud/systemd-docker#readme, and you will clearly see that—while SystemD does launch the process using that syntax—there's much more to it than that.

@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 20, 2018

I did. The initial problem is that Systemd monitors docker client and not the container.
How this is better in this case? I don't see it. In every line docker client is used.

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1

I did. The initial problem is that Systemd monitors docker client and not the container.
How this is better in this case? I don't see it. In every line docker client is used.

ExecStartPre=/usr/bin/docker run -d --name container1 some-image
ExecStart=/usr/bin/docker logs -f contaner1
@ibukanov

This comment has been minimized.

Show comment
Hide comment
@ibukanov

ibukanov Apr 20, 2018

@aholbreich If docker client dies, with just ExecStart=/usr/bin/docker run systemd consider the unit as failed when the container in fact runs.

@aholbreich If docker client dies, with just ExecStart=/usr/bin/docker run systemd consider the unit as failed when the container in fact runs.

@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 20, 2018

@ibukanov ok, belive you & will try..
but strange that if "docker client dies"
this Commant should work further....

ExecStart=/usr/bin/docker logs -f contaner1

it's still docker client or not? & also don't kills container if dies... also wrong state. Why it works in this case?

aholbreich commented Apr 20, 2018

@ibukanov ok, belive you & will try..
but strange that if "docker client dies"
this Commant should work further....

ExecStart=/usr/bin/docker logs -f contaner1

it's still docker client or not? & also don't kills container if dies... also wrong state. Why it works in this case?

@dashesy

This comment has been minimized.

Show comment
Hide comment
@dashesy

dashesy Apr 20, 2018

I used this to tell systemd when client dies:

#!/bin/bash

function docker_cleanup {
    docker exec $IMAGE bash -c "if [ -f $PIDFILE ]; then kill -TERM -\$(cat $PIDFILE); rm $PIDFILE; fi"
}

IMAGE=$1
PIDFILE=/tmp/docker-exec-$$
shift
trap 'kill $PID; docker_cleanup $IMAGE $PIDFILE' TERM INT
docker exec $IMAGE bash -c "echo \"\$\$\" > $PIDFILE; exec $*" &
PID=$!
wait $PID
trap - TERM INT
wait $PID

One big problem with -d is that logs will not go to journald

dashesy commented Apr 20, 2018

I used this to tell systemd when client dies:

#!/bin/bash

function docker_cleanup {
    docker exec $IMAGE bash -c "if [ -f $PIDFILE ]; then kill -TERM -\$(cat $PIDFILE); rm $PIDFILE; fi"
}

IMAGE=$1
PIDFILE=/tmp/docker-exec-$$
shift
trap 'kill $PID; docker_cleanup $IMAGE $PIDFILE' TERM INT
docker exec $IMAGE bash -c "echo \"\$\$\" > $PIDFILE; exec $*" &
PID=$!
wait $PID
trap - TERM INT
wait $PID

One big problem with -d is that logs will not go to journald

@ibukanov

This comment has been minimized.

Show comment
Hide comment
@ibukanov

ibukanov Apr 20, 2018

@aholbreich See my comments above with ExecStop/ExecStopPost that ensures that the container stops when the client dies.

But these days if ever need to start a docker container from a systemd unit with docker, I will create the container outside systemd scripts in a provision script via docker create --restart=unless-stopped --log-driver=journald ... and use something like:

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=docker start mycontainer
ExecStop=docker stop mycontainer

This avoids running useless docker client, delegates restarting the container if it fails to Docker while still allowing to log to journald and letting systemd to start/stop the container to satisfy dependencies. The drawback is that stopping container via manual docker stop will not be reflected in systemd, but depending on deployment it can be even useful for debugging etc.

@aholbreich See my comments above with ExecStop/ExecStopPost that ensures that the container stops when the client dies.

But these days if ever need to start a docker container from a systemd unit with docker, I will create the container outside systemd scripts in a provision script via docker create --restart=unless-stopped --log-driver=journald ... and use something like:

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=docker start mycontainer
ExecStop=docker stop mycontainer

This avoids running useless docker client, delegates restarting the container if it fails to Docker while still allowing to log to journald and letting systemd to start/stop the container to satisfy dependencies. The drawback is that stopping container via manual docker stop will not be reflected in systemd, but depending on deployment it can be even useful for debugging etc.

@aholbreich

This comment has been minimized.

Show comment
Hide comment
@aholbreich

aholbreich Apr 21, 2018

Ok, with all the drawbacks of the proposed workarounds i'm gona continue direct use of:

ExecStart=/usr/bin/docker run --name container1 some-image

i think docker or systemd (probably systemd) should improve this in the future...
But for now, since i had no issues with this, causing any problem so far, don't see any reason to overcomplicate...

aholbreich commented Apr 21, 2018

Ok, with all the drawbacks of the proposed workarounds i'm gona continue direct use of:

ExecStart=/usr/bin/docker run --name container1 some-image

i think docker or systemd (probably systemd) should improve this in the future...
But for now, since i had no issues with this, causing any problem so far, don't see any reason to overcomplicate...

@ubergesundheit

This comment has been minimized.

Show comment
Hide comment
@ubergesundheit

ubergesundheit Jul 12, 2018

Sorry for maybe asking an unrelated question, if this is the cast I'll happily delete my comment and ask the question somewhere more appropriate!

I assume this issue also applies to running containers via docker-compose? I sense docker-compose just amplifies everything by bringing another layer between the container and systemd?

Sorry for maybe asking an unrelated question, if this is the cast I'll happily delete my comment and ask the question somewhere more appropriate!

I assume this issue also applies to running containers via docker-compose? I sense docker-compose just amplifies everything by bringing another layer between the container and systemd?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment