Steve,
Ok, let me start with the YSF Reflector error.  Attached is the reflector log file from 3/27/21 which shows the error message occurring approximately 4 full screens from the top of the file.  I have 3 servers running XLX and YSF and bridges from them to our hblink3 hub.  All 3 YSF Reflectors at sometime from startup will fail with that double clear error.  Each reflector may run for 1 plus hours or more or may run for 1 to 3 days, but at some point this error occurs and they shutdown.  Using the latest YSFReflector code from github.
The P25 and NXDN reflector errors are somewhat similar in that they will startup and run and bridge to the master hub.  Again we are using the latest versions of reflector code from github (G4KLX).  I don't have any log files which show they stop working, but what seems to occur is at the same frequency as above for YSF reflector, they will stop responding.  I know that the Gateways are still working as restarting the gateway does not restart the connection to the master.  The MMDVM_Bridge is still running as well.  To get the reflector to start bridging again, I need to execute the P25Reflector.sh and do a 'reload' which stops the reflector and then do a start.  Sometimes on the NXDN reflector when it stops if I just do the script command "NXDNReflector.sh start /etc/NXDNReflector.ini &" I get a message that the reflector is already running.  But no connection can be made to the reflector, so I just do the reload and then start command and all is well again, so the gateway and MMDVM_Bridge do not appear to be the problem, only the reflectors.  Again we are running three sets of P25 and NXDN reflectors with bridging on three individual servers.  The reflector logs do not show any problem or error message.  I have tried both the DVSwitch installed gateway code and also the gateway code from github wihich is a later version by date, but neither makes any difference.  Also I have tried different versions of Analog_Bridge for the P25 and different versions of MMDVM_Bridge for both P25 and NXDN, but as above I don't think these affect the problem.  I can send my .ini files if you want to see them.  Sometimes either the P25 or NXDN bridge will instead of stopping will have a extremely long latency, which listening on the DMR side of the bridge will sound like a 78 speed record running at 33.3 speed.  Again, just by issuing a P25 or NXDN script reload and then restart this problem disappears until sometime later.  All this has happened since we decided to move all our reflectors and bridges to new cloud servers (cheaper cost).  Did not have these problems with the original servers which were using the older DVSwitch modules.  Now we are using the DVSwitch-Server modules (not saying that DVSwitch is the problem, just trying to figure out what has changed).  Using the same server provider, just downsizing from 4 core to 2 core with less hard drive space needed.
Also have noticed by looking at the server stats that when using Analog_Bridge version 1.6.1 that if I use it as the second Analog_Bridge needed for P25 to DMR (creating a separate executable and .ini file that my CPU stats go way up over 50%, so switching the second Analog_Bridge executable with version 1.4.2 does not cause the high CPU usage.  Also needed to turn off Analog_Bridge logging as I was getting continuous messages in the Analog_Bridge log file stating successful running of something (can't remember), but was filling up the allotted memory if I did not stop the logging.  
Sorry for the long book.
--
Dave WB6DTB