WantedBy doesn't lead to starting service

[l15k4]

Hey,

I have 2 services es and es-discovery ... es needs es-discovery. If es declares Wants=es.discovery.service everything works as expected and when I start es then es-discovery is started too. But if I declare WantedBy=es in es-discovery service then units are created properly (es unit Wants es-discovery) but es-discovery never starts. This is the result of loading both but starting just es : http://pastebin.com/raw.php?i=kmATHbGD

es@.service :

[Unit]
Description=Elasticsearch Service
Wants=es-data@%i.service log-entries@%i.service
After=es-data@%i.service log-entries@%i.service

[Service]
TimeoutStartSec=0
Restart=always
RestartSec=30
EnvironmentFile=/etc/environment
TimeoutStopSec=30

ExecStartPre=-/usr/bin/docker kill %p-%i
ExecStartPre=-/usr/bin/docker rm %p-%i
ExecStartPre=-/usr/bin/docker pull gwiq/es-prod

ExecStart=/bin/bash -c '\
  curl -f ${COREOS_PRIVATE_IPV4}:4001/v2/keys/services/es; \
  if [ "$?" -eq 0 ]; then \
      UNICAST_HOSTS=$(etcdctl ls --recursive /services/es \
                      | sed "s/\/services\/es\///g" \
                      | sed "s/$/:9300/" \
                      | paste -s -d","); \
  else \
      UNICAST_HOSTS=""; \
  fi; \
  /usr/bin/docker run \
    --name %p-%i \
    --publish 9200:9200 \
    --publish 9300:9300 \
    --volumes-from es-data-%i \
    -e ES_DISCOVERY_UNICAST_HOSTS=$UNICAST_HOSTS \
    -e ES_NETWORK_PUBLISH_HOST=$COREOS_PRIVATE_IPV4 \
    -e ES_NODE_NAME=%p-%i \
    --env-file /opt/coreos-services/project/es/env \
    gwiq/es-prod'

ExecStop=/bin/bash -c '\
    curl -XPOST -fSs ${COREOS_PRIVATE_IPV4}:9200/_cluster/nodes/_local/_shutdown > /dev/null; \
    sleep 10;'

ExecStopPost=/usr/bin/docker stop %p-%i
ExecStopPost=-/usr/bin/docker rm %p-%i

[X-Fleet]
Conflicts=%p@*.service
MachineOf=es-data@%i.service

es-discovery@.service

[Unit]
Description=Elasticsearch Discovery Service
Requires=etcd2.service cluster-init.service
After=etcd2.service cluster-init.service
Before=es@%i.service
BindsTo=es@%i.service

[Service]
Restart=always
EnvironmentFile=/etc/environment

ExecStart=/bin/bash -c '\
  while true; do \
    etcdctl set /services/es/${COREOS_PRIVATE_IPV4} \'{"http_port": 9200, "transport_port": 9300}\' --ttl 30; \
    sleep 20; \
  done'

ExecStop=/usr/bin/etcdctl rm /services/es/${COREOS_PRIVATE_IPV4}

[Install]
WantedBy=es@%i.service

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

If I just move WantedBy from es-discovery to Wants in es then it works... But I need WantedBy because es service shouldn't know about the discovery...

If I start the service explicitly afterwards, it starts...

I suspect that the problem might be that the ExecStart process blocks because there is never ending while loop.

[mischief]

afaik, the [Install] section is not used by fleet. [Install] is used by systemd when you run e.g. 'systemctl enable foo.service'. fleet does not 'enable' units. it starts or stops them.

[l15k4]

The resulting unit looks as it should in systemd, ie. the Wants relationship is created, you can see that in the pastebin, however starting the unit doesn't invoke starting the wanted unit... It might be a systemd bug then...

Btw I'm loading all of them, I just think that fleetctl start unit that Wants another loaded unit should start the another one too...

[jonboulle]

I think what you really want here is #464 so I'm going to close this in favour of that, please re-open if you feel otherwise.

[l15k4]

What I'm reporting here is this :

1. A-Wants-B
2. fleetctl load B A && fleetctl start A
3. both A and B are ACTIVE

BUT

1. B-WantedBy-A
2. fleetctl load B A && fleetctl start A
3. only A is started eventhough fleetctl cat A shows it Wants B <- so it should behave the same as the first case

@jonboulle you probably thought that I'm not loading both of them right? But I do, so cluster level relationships between units X-Fleet X-Requires are irrelevant to this issue.

[jonboulle]

We could potentially achieve this using EnableUnitFiles. Worth investigating.

[antrik]

@jonboulle you mean we should try what happens if we always enable unit files after loading them? (Or maybe before starting? Don't know which is more appropriate...)

[jonboulle]

@antrik Right - instead of just writing them to disk and doing a daemon-reload, what if we actually ran enable on them at the time that they're loaded? which AIUI transitively involves the equivalent of a reload. Maybe this would be more expected behaviour..

[kayrus]

AddDependencyUnitFiles Dbus method was introduced in systemd v217. systemd/systemd@e94937d#diff-b3e16bf39e5d7ab233077b9b1dafb095R1807

We can use this method to process only WantedBy and RequiredBy options and ignore other [Install] options.

[kayrus]

There is no RemoveDependencyUnitFiles / DeleteDependencyUnitFiles so it will be hard to maintain destroy/unload/--replace

[kayrus]

DisableUnitFiles should work fine. And it is already used in func removeUnit