@vladimir-d The only other case an app is restarted without anyone triggering it is if an app using the tls addon had the certificate renewed. Unless this is a custom app, there is only the AdGuardHome app that uses the tls addon. So, is this app AdGuard Home?
I think you can get more insight by looking into the corresponding logs at the lines above those lines. What does it say above the lines you posted?
Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.
So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.
Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.
Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
@robi for the first logviewer mismatch, this is because the first time shown is from the logservice itself and is translated into the local time of your browser, whereas the second comes from the app itself and is just treated as a plain string. Apps normally run in UTC.
For the winscp part, I am not sure how winSCP translates timestamps. The folder names are set from server time.
I don't think any of this will have anything to do with DB reconnection, if you have any issue there, please make a new entry in the TS forum section with some more info.
I wasn't talking about fail2ban reporting, only. I was also referring to the built-in "rate-limiting" of Cloudron (and other security features, e.g. the cloud firewall) where there's currently little or no transparency what's happening.
Since Cloudron "takes over the server" I think it would be a good opportunity to add transparent monitoring of the system's security features similar to the "System info" tab...
Can you describe the use-case a bit further? Cloudron already collects logs for each application and addon, as well as the Cloudron related platform components. Generally it is not supported to install other daemons on the side of Cloudron on the same server, since we cannot test such configurations during updates.
FYI all the logs are collected currently as described here https://cloudron.io/documentation/troubleshooting/#logs
@girish Went ahead and tried it and it works beautifully! Took a matter of seconds for it to load all my feeds. Really appreciate y'all's work on this. I'm becoming a bigger Cloudron fan by the minute 🙂