Unable to create a package in wingetty for large installble

[Nizamc]

Describe the bug
I'm trying to upload a nested installer that is a hefty 4.5 GB (install.zip). Nothing seems to happen in the GUI once the upload is complete, but I see a message in the log like: [1] [CRITICAL] WORKER TIMEOUT.

To Reproduce
Steps to reproduce the behavior:

1. Click Add Package
2. Fill out form, and select an installer that's large enough to trigger the timeout
3. Wait
4. See error in logfile

Expected behavior
Package should be available for install in wingetty.

Screenshots

General Information:

• WinGetty version 0.0.9
• Browser [e.g. chrome, safari] (if website related)

Additional context
Add any other context about the problem here.

[thilojaeggi]

Have you tried updating to version 1.0.0?

[Nizamc]

we tried to update to latest, it seems v1.0.0, is not stable version.. it was giving application timeout(unable to open web application). Hence revert back to 0.0.9

[Nizamc]

@thilojaeggi any update on above reported issue. How to resolve this?

[Idah00]

Hello, I'm facing the same issue with the 1.0.0 version (the problem seems to exist with packages around 700MB and more), I have tried a few things to solve the issue:

• making sure my nginx is configured properly (it seems to be)
• modifying the start.sh file to allocate more workers, threads and set a higher timeout to them

None of this seems to be working.

My Wingetty instance is running on a qemu VM setup on debian 12 (that's how my boss does things to host servers)

Do you have any of idea what might be wrong? If I can be of any help to pinpoint this issue I'd be glad to oblige.

Thanks a lot for your help and your work on the project, we've been using Wingetty for a few months now and we like it a lot but this issue is kind of a roadblock tbh...

Edit: Today I tried uploading my package directly on the server and therefore upload it directly through HTTP and not by HTTPS to bypass nginx and see if it was indeed a problem with nginx or not, the loading would go around 60/70% then start again, go again to 60/70% and then stop, the upload interface would still be there as if nothing happened and I would not see any package added to the repo but I'm not getting any error message...

I'm starting to think this might be a ressource issue but my VM that runs the server has 8 cores and 16GB of RAM and the QEMU server does not seem to be at its limits...

[Xrist0ff]

I have the same issue with docker environnement (wingetty + nginx) .
The package around 600 MB.
Wingetty log:
[2024-12-30 13:30:55 +0100] [10] [DEBUG] POST /api/add_package
[2024-12-30 13:31:17 +0100] [10] [INFO] [WinGetty] File and version found
[2024-12-30 13:31:25 +0100] [1] [CRITICAL] WORKER TIMEOUT (pid:10)
[2024-12-30 13:31:25 +0100] [10] [DEBUG] Closing connection.
[2024-12-30 13:31:25 +0100] [10] [INFO] Worker exiting (pid: 10)
[2024-12-30 13:31:26 +0100] [1] [WARNING] Worker with pid 10 was terminated due to signal 9

I try to increase timeout and client_max_body_size but that's no effect.

[Nizamc]

@thilojaeggi Can you respond please

[thilojaeggi]

I’m currently tied up with other projects and, to be honest, lacking the motivation to continue working on WinGetty at the moment. With a full-time job and no GitHub sponsors supporting this, it’s been challenging to dedicate the time it deserves. That said, you’re absolutely welcome to submit a pull request if you find a solution to this issue—I’d greatly appreciate your contribution!

[thilojaeggi]

For a hacky workaround you could either use another server for hosting files and then add them via the custom URL form field or use a S3 compatible storage backend such as Cloudflare R2 or something like https://github.com/minio/minio