Unit does not automatically start Required units

[dknell]

I would like to be able to start a single unit and have another required unit start automatically.

This may not be supported by fleet or I'm misunderstanding the systemd documentation, but from what I'm reading in the systemd.unit documentation I should be able to start a unit and it will automatically start any unit that is listed in the Requires. Is this possible or am I doing something wrong?

This is a simple test:

busy.service

[Unit]
Description=BusyBox Test
After=docker.service
Requires=docker.service
Requires=busy-watch.service

[Service]
ExecStart=/usr/bin/docker run busybox /bin/sh -c "while true; do echo Hello World; sleep 20; done"

busy-watch.service

[Unit]
Description=BusyBox Test Watcher
BindsTo=busy.service

[Service]
ExecStart=/bin/sh -c "while true; do etcdctl set /tasks/busy/running 'yes' --ttl 60;sleep 45;done"
ExecStop=/usr/bin/etcdctl rm /tasks/busy/running

[X-Fleet]
X-ConditionMachineOf=busy.service

Add the units to fleet:

fleetctl submit busy*.service

Units are available to run:

core@core-01 ~ $ fleetctl list-units
UNIT            LOAD    ACTIVE  SUB DESC            MACHINE
busy-watch.service  -   -   -   BusyBox Test Watcher    -
busy.service        -   -   -   BusyBox Test        -

By starting busy.service, I would expect busy-watch.service to also start:

core@core-01 ~ $ fleetctl start busy.service
Job busy.service scheduled to 4621f512.../172.17.8.102

Neither units are running:

core@core-01 ~ $ fleetctl list-units
UNIT            LOAD    ACTIVE  SUB DESC            MACHINE
busy-watch.service  -   -   -   BusyBox Test Watcher    -
busy.service        -   -   -   BusyBox Test        -

Just to make sure that the units are functional and that there are no syntax errors, I tried removing Requires=busy-watch.service and start both of the units together.

core@core-01 ~ $ fleetctl start busy.service busy-watch.service
Job busy.service scheduled to 4621f512.../172.17.8.102
Job busy-watch.service scheduled to 4621f512.../172.17.8.102
core@core-01 ~ $ fleetctl list-units
UNIT            LOAD    ACTIVE  SUB DESC            MACHINE
busy-watch.service  loaded  active  running BusyBox Test Watcher    4621f512.../172.17.8.102
busy.service        loaded  active  running BusyBox Test        4621f512.../172.17.8.102

[bcwaldon]

@dbubs I'd love to hear your thoughts on the new load step introduced in fleet v0.3.0.

[dknell]

@bcwaldon the load command does not really solve the problem of starting required units. It would be nice to be able to start a "master" unit and have all of the required units start automatically. That's what the systemd manual claims. For now starting all of the units in a single command will suffice.

[jonboulle]

@dbubs We're considering adding an X-Requires directive (i.e. in the X-Fleet section), which would provide the behaviour you're after at a cluster level.

[dknell]

@jonboulle That would be perfect!

[jalev]

Just to add: I seemed to 'solve' this by loading all services prior to starting them. It seems as though fleet does not want to do any dep-management for services that aren't loaded (at least, fleet v0.3.2).

[jonboulle]

@qweet: fleet doesn't do any of that kind of management at all at this stage; Requires/Wants/Before/After are all handled directly by systemd, which is why you're not seeing anything "act" on them before the point of loading the units. As I mentioned in my previous comment, we would create a new explicit directive (something like X-Requires) for fleet to handle these kind of dependencies at a cluster level.

[carmstrong]

We're considering adding an X-Requires directive (i.e. in the X-Fleet section), which would provide the behaviour you're after at a cluster level.

+1000. This is really something we'd like to see.

[nakosung]

+1000. X-Requires, X-After, ... are needed desperately.

[aberman]

Has any work been done on this? I really need this sort of functionality as well.

[bcwaldon]

@aberman No. We have not been focusing on increasing the scope of the cluster-level behaviors such as Requires, After, etc.

[bcwaldon]

I'd like to understand why the general feeling is that this needs to be a first-class behavior in fleet. Is it the pain of having to call fleetctl load foo.service bar.service && fleetctl start foo.service, or is there something more?

[dknell]

@bcwaldon
Short answer - configuration over convention.

Less-short answer - From an automation standpoint, I would want to declare all of my unit requirements in the unit files and then only have to control (start, stop, destroy) a single unit and all of the "required" units automatically perform the same commands. I may not always run fleetctl start ... from the coreos command line. Perhaps I want to create an automation tool to start a cluster of units and their requirements. My automation tool should not have to know about the requirements - more so if I've already specified them in my unit files.

I hope that makes sense. :)

[imchairmanm]

I would like to see this happen as well. Especially since the sidekick paradigm seems to be suggested so often as a way to handle etcd registration.

For me, if my unit files are set up as follows:

• Main unit has Requires= and After= directives which point to a sidekick
• Sidekick has a BindsTo= which points back to the main unit

I would expect for my dependency bases to be covered.

When I see the fleetctl help start information that defines the command as:

Instruct systemd to start one or more units in the cluster, first submitting and loading if necessary.

This leads me to assume that if I type fleetctl start main.service, that it will bring the target unit into the desired state, but also that the sidekick would get started since that is declared as a dependency.

It was really unexpected for me that the tool doesn't do this since both the pieces are there. It caused me to spend a lot of time debugging unit files that were actually perfectly okay. In my troubleshooting, I came across quite a few other people who had made the same assumption.

[mwhooker]

+1

Our use case is we want to run the docker registry in mirror mode and stick it on one of our nodes. We'd like this to be the first thing to come up before any other units which pull docker images do, so rather than coordinating through etcd, a more semantic approach supported by fleet would make our lives a lot easier.

[bytesandwich]

+1
I'd love to see this.
I want to have one service that requires a bunch of others

[Unit]
Requires=postgres-master.service
After=postgres-master.service
Requires=postgres-master-announce.service
After=postgres-master-announce.service
Requires=postgres-replica@1.service
After=postgres-replica@1.service
Requires=postgres-replica-announce@1.service
After=postgres-replica-announce@1.service
Requires=postgres-replica@2.service
After=postgres-replica@2.service
Requires=postgres-replica-announce@2.service
After=postgres-replica-announce@2.service

[marszall87]

+1

[niquola]

👍

[wricardo]

+1

[mvanholsteijn]

+1
you really need this to be part of the scheduling. In my case, I want to mount a device before running a service.

[kgorskowski]

+1

[ghost]

Is this in the works right now? We'd also like to use this... and hit the same issues as @imchairmanm described.

[pacuna]

+1

[marcovc]

+1

[djmaze]

+1

[ghost]

@bcwaldon - Are the previous explanations of why this is requested to be a first-class behaviour sufficient?

[bcwaldon]

Yes, I can see how supporting Requires in X-Fleet would be useful.

[komex]

+1

[wuqixuan]

+10000, we need support this to make other management script simple.

[bgoldman]

👍

[h0tbird]

+1