Q:

What does puppet do to fix a 'stuck' systemctl service where systemctl would refuse to start a service? 

We had a scenario where on RHEL we couldn't start an application that had been running and we had just stopped.  
sudo systemctl start myservice

We didn't have access to the journald logs on this server, so the state of the server was a mystery.  
The application instance didn't 'start' as it logs verbosely, and yet the application logs weren't touched.  
My friend came along and run a puppet agent update on this box:
puppet agent --environment=production --test

After this - we could stop and start the service.  
I understand that puppet has the ability to remove and create a service, and also to 'daemon-reload'.  ie something like
systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
systemctl daemon-reload
systemctl reset-failed

Now I'm realising in retrospect that I should have run 
sudo systemctl reset-failed

I'm trying to work out what the specific thing that puppet does to get a 'stuck' service to work.  
My question is: What does puppet do to fix a 'stuck' systemctl service where systemctl would refuse to start a service? 

A:

I got access to the journald logs and found out the following.  
Interestingly enough a service will not start if the disk is full.  
Puppet when running can choose to run a 
yum clean all

Which fixes the issue and enables a service to start. 