O1ahmad/ansible-role-systemd

Why does preflight flush handlers?

Opened this issue · 3 comments

Our roles (that install software) are generally structured in the following way:

  • prepare users, directories, configs etc.
    • notify service restart handler when anything changes
  • use 0x0i.systemd to create and start the service
  • do any tasks that require the software to run (call APIs atc.)

I strongly believe this is the correct way to do things (make sure services start in the correct environment, with correct configs etc.) but 0x0i.systemd makes this impossible, because it flushes handlers at the start (in common/preflight.yml), making Ansible to try and restart services that don’t exist yet.

I am not sure why is it written this way (looking at the history didn't tell me much). Would it be possible to make the handler flush optional, or maybe remove it completely?

I introduced this change for the reasons described in 0830abc

In particular, if the configuration of a service changes and its state is set to "started", then we need to restart it.
And it has to be done before the task "Activate configured Systemd units".
And it is convenient that it is done by this role instead of being duplicated at each calling place.

Note: I don't believe that notifying the restart of services that do not exist yet is a good idea. Couldn't you ensure that there is a minimal working configuration for your service so that it can start at any time?

Oh you were speaking specifically about preflight, I was not but maybe still this is maybe the flush of the handlers that causes your issue?

Hi,

sorry for the late reply. I am specifically talking about the preflight handler flush (or any that happens before the unit files are created). I am completely on board with restarting services with new or changed unit files (as this is the way to make sure the change gets applied), it's only the early flush that causes issues.

Note: I don't believe that notifying the restart of services that do not exist yet is a good idea.

Why? In my mind, handlers are a way to delay an action until things are ready (and to the action only once): this is exactly what I am trying to do.

Couldn't you ensure that there is a minimal working configuration for your service so that it can start at any time?

Not really: the service needs to connect to a database, and that database runs on a different host.

Also, looking at things from different angle, this is exactly what I am trying to do: to ensure there's a valid configuration so that the service can start immediately. (And as the configuration might change, I need to make sure the service will be properly restarted; therefore notify handler.) The issue is, the systemd role doesn't ensure this: it tries to restart the service (by flushing handlers) before it is ready (i. e. before it creates the unit file).