I raised the priority for this as this seems to be a recurrent situation. Each time I
check this, it's right there, at least 3 refresh at the same time.

The computation of those metrics will be executed in production on a regular basis, probably each day, to keep them up to date.

Build is green

It seems the systemd module upgrade add an internal change :

*******************************************
  Systemd::Service_limits[rabbitmq-server.service] =>
   parameters =>
     selinux_ignore_defaults =>
      + false

but as we have checked together, it seems it has no impacts on the service configuration / content of the dropin files

rebase

Drop no longer needed cron part.

Update to 2.12 (updating the fork source we host on the forge)

What i just said from the appropriate repository

Implement the diff as systemd service/timer instead of a cron. This also installs said
service for a daily execution instead of hourly (as per the related task discussion).

Indeed, a quick htop which demonstrates it:

It looks like it solves the concurrency issue and will allow to keep the logs

Ah interesting.
Let's try and do that ;)

If there any log in output? Is-it possible to monitor the duration of the command

I have just saw the paste so I have the response to my first question ;)

If there any log in output? Is-it possible to monitor the duration of the command and most importantly avoiding it to run several times in parallel?