ExecStop is not being called

316 views
Skip to first unread message

Ginger

unread,
Sep 15, 2015, 5:00:20 AM9/15/15
to CoreOS User
Hello all,

I have the following services (main + sidekick):

Main unit: test@.service
[Unit]
After=etcd2.service
After=docker.service
Requires=etcd2.service
Requires=docker.service
Wants=test-sidekick@%i.service

[Service]
Restart=always
KillMode=none
ExecStartPre=/usr/bin/docker pull ubuntu
ExecStart=/usr/bin/docker run --name test-%i ubuntu /bin/bash -c "while true; do echo hello; sleep 5; done"
ExecStop=/usr/bin/docker stop test-%i
ExecStopPost=/usr/bin/docker rm test-%i

Sidekick unit: test-sidekick@.service
[Unit]
BindsTo=test@%i.service
After=test@%i.service

[Service]
ExecStart=/bin/bash -c "while true; do /usr/bin/etcdctl set /test %i; sleep 5; done"
ExecStop=/usr/bin/etcdctl rm --recursive /test

[X-Fleet]
MachineOf=test@%i.service

When I do a fleetctl destroy on a running instance, the main ExecStop is not being executed. The ExecStop of the sidekick unit is being executed. So in the end the etcd key is removed but the container is still up and running. If I change the ExecStop directive in the sidekick from /usr/bin/etcdctl rm to a /usr/bin/echo "STOP", everything works fine.

G

unread,
Sep 15, 2015, 5:02:30 AM9/15/15
to CoreOS User
Is this a known bug or am I missing something?

kyle....@coreos.com

unread,
Sep 15, 2015, 2:45:18 PM9/15/15
to CoreOS User

Hello,

Can you explain your reasoning behind setting Restart=always in the main unit?

Brandon Philips

unread,
Sep 15, 2015, 6:54:02 PM9/15/15
to G, CoreOS User
Can you run systemctl status on the test@ unit? Is it just waiting to be stopped? Perhaps try changing docker stop to docker kill? Perhaps the container isn't respecting the SIGTERM or is taking a long time to stop?

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

G

unread,
Sep 16, 2015, 5:45:26 AM9/16/15
to CoreOS User, ginge...@gmail.com
@Brandon, as per systemctl status:

● te...@1.service
   Loaded: not-found (Reason: No such file or directory)
   Active: deactivating (stop-sigterm) since Wed 2015-09-16 12:41:40 EEST; 22s ago
 Main PID: 5803 (docker)
   CGroup: /system.slice/system-test.slice/te...@1.service
           └─5803 /usr/bin/docker run --name test-1 ubuntu /bin/bash -c while true; do echo hello; sleep 5; done

Sep 16 12:41:28 coreos-01 docker[5761]: Status: Image is up to date for ubuntu:latest
Sep 16 12:41:28 coreos-01 systemd[1]: Started te...@1.service.
Sep 16 12:41:28 coreos-01 docker[5803]: hello
Sep 16 12:41:33 coreos-01 docker[5803]: hello
Sep 16 12:41:38 coreos-01 docker[5803]: hello
Sep 16 12:41:40 coreos-01 systemd[1]: Stopping te...@1.service...
Sep 16 12:41:43 coreos-01 docker[5803]: hello
Sep 16 12:41:48 coreos-01 docker[5803]: hello
Sep 16 12:41:53 coreos-01 docker[5803]: hello
Sep 16 12:41:59 coreos-01 docker[5803]: hello


and after a couple of minutes it changes to:
● te...@1.service
  Loaded: not-found (Reason: No such file or directory)
  Active: failed (Result: signal) since Wed 2015-09-16 12:32:25 EEST; 2min 8s ago
  Main PID: 2798 (code=killed, signal=KILL)

Sep 16 12:32:02 coreos-01 docker[2798]: hello
Sep 16 12:32:07 coreos-01 docker[2798]: hello
Sep 16 12:32:12 coreos-01 docker[2798]: hello
Sep 16 12:32:17 coreos-01 docker[2798]: hello
Sep 16 12:32:22 coreos-01 docker[2798]: hello
Sep 16 12:32:25 coreos-01 systemd[1]: te...@1.service: State 'stop-sigterm' timed out. Killing.
Sep 16 12:32:25 coreos-01 systemd[1]: te...@1.service: Main process exited, code=killed, status=9/KILL
Sep 16 12:32:25 coreos-01 systemd[1]: Stopped te...@1.service.
Sep 16 12:32:25 coreos-01 systemd[1]: te...@1.service: Unit entered failed state.
Sep 16 12:32:25 coreos-01 systemd[1]: te...@1.service: Failed with result 'signal'

And the container is still up and running (regardless whether I use stop or kill). 10 minutes after destroying the unit, the container is still there 

@Kyle, I used Restart=always for obvious reasons: I wanted to have the service restarted in case of failure. Is this a problem? If yes, then how / where should I use it?
Reply all
Reply to author
Forward
0 new messages