Support systemd notifications after communication with a physical backend is established

[jen20]

Is your feature request related to a problem? Please describe.

There is no good way right now to chain systemd jobs from a Vault server and have them start only when that Vault server is ready to accept "requests" (usually an unseal).

Describe the solution you'd like

The same solution that Consul has implemented - the ability to notify systemd when startup is complete and the system is ready to handle requests. This was merged here: hashicorp/consul#3164

[jefferai]

Sounds neat, would you be willing to submit a PR?

[JulienBalestra]

I'm interested by this feature in the vault agent too.
I'd like to know if it's possible to submit a PR with the coreos library sdnotify for this ?

[chmarr]

A simple workaround would be to add a ExecStartPost to the vault.service, through a drop-in (/etc/systemd/system/vault.service.d/mything.conf)

The ExecStartPost program would wait until vault became ready – perhaps by test-polling – then exit.

vault.service will not become "activated" until all the ExecStartPost commands have completed successfully, and thus "After=vault.service" services will not be started until that point.

systemd-notify support directly in the application is considerably cleaner, though.

[aphorise]

@JulienBalestra there was #9802 as a recent systemd inclusion for agents which may be of interest if anyone wants to propose a DR for what's asked.

Aside from the suggestion from @chmarr - I'm thinking it may actually be a bit more of a challenge in the case of all 20+ storage backend types to do this. What may be an another approach is to have a read (like continues KV2 read) or some other event watched for in TRACE level logs of Vault for something unique to when everything is in sync / ready.

@jen20 can confirm how this is relevant for you still?