This will end up flooding the activity logs due to the way SFTP works, we'll need to have an intermediate step in Wings that batches events every 10 seconds or so and submits them as a single "event" for activity.
commit f5baab4e88
Author: DaneEveritt <dane@daneeveritt.com>
Date: Sat Jul 9 17:50:53 2022 -0400
Finalize activity event sending logic and cron config
commit 9830387f21
Author: DaneEveritt <dane@daneeveritt.com>
Date: Sat Jul 9 16:26:13 2022 -0400
Send power events in a more usable format
commit 49f3a61d16
Author: DaneEveritt <dane@daneeveritt.com>
Date: Sat Jul 9 15:47:24 2022 -0400
Configure cron to actually send to endpoint
commit 28137c4c14
Author: DaneEveritt <dane@daneeveritt.com>
Date: Sat Jul 9 15:42:29 2022 -0400
Copy the body buffer otherwise subsequent backoff attempts will not have a buffer to send
commit 20e44bdc55
Author: DaneEveritt <dane@daneeveritt.com>
Date: Sat Jul 9 14:38:41 2022 -0400
Add internal logic to process activity events and send them to the panel
commit 0380488cd2
Author: DaneEveritt <dane@daneeveritt.com>
Date: Mon Jul 4 17:55:17 2022 -0400
Track power events
commit 9eab08b92f
Author: DaneEveritt <dane@daneeveritt.com>
Date: Mon Jul 4 17:36:03 2022 -0400
Initial logic to support logging activity on Wings to send back to the panel
* fix: arm64 docker builds
Don't hardcode amd64 platform for the Wings binary.
* update docker file
don't specify buildplatform
remove upx as it causes arm64 failures
remove goos as the build is on linux hosts.
Co-authored-by: softwarenoob <admin@softwarenoob.com>
Due to the order of the previous logic in ScanReader, an error not caused by EOF would effectively get ignored since an error will always be returned with `isPrefix` equal to false, thus triggering the first break, and error checking is not performed beyond that point.
Thus, canceling an installation process for a server while this process was running would hang the routine and cause the loop to run endlessly, even with a canceled context.
If my debugging is correct, this should address pterodactyl/panel#3903 in its entirety by addressing a few areas where it was possible for a channel to lock up and cause everything to block
JSON has a huge amount of overhead from Docker when we're trying to process large amounts of log data. It makes more sense to just use a better format.
This also removes server process termination logic when a server is breaching the output limits. It simply continues to efficiently throttle the console output.
