ReportLab issues
Oskar Laubsch
Hello everyone,
We recently encountered a persistent issue while deploying Eden under uWSGI. The application started throwing 500 errors, and instead of showing a proper ticket, it entered into an endless ticket loop: Eden attempted to generate a ticket, but could not write to the errors/ folder. Each attempt to render a ticket resulted in another ticket being created, which also could not be written, and the loop repeated indefinitely.
During troubleshooting together with Dominic, we identified that the problem was related to filesystem permissions and ReportLab. The Eden process was running as the web2py user, but directories such as applications/eden/errors, sessions, uploads, etc. were root-owned, preventing the application from writing tickets. At the same time, ReportLab failed at startup in rl_config.py with a FileNotFoundError, because it could not resolve $HOME or create .reportlab_settings.
We tried multiple approaches: fixing ownership with chown -R web2py:web2py, adjusting directory permissions, manually creating .reportlab_settings, forcing HOME=/home/web2py in the uwsgi.ini, reinstalling ReportLab both via apt and pip, and even testing different versions (3.5.x vs 3.6.x).
Despite these attempts, the issue persisted and the environment remained unstable. The only workaround we found that avoided a full reinstall was to completely disable ReportLab — but that meant losing all PDF generation functionality. In the end, the only way to move forward was to completely reinstall the environment — web2py, Eden, PostgreSQL, and dependencies — from scratch.
The outcome was unsatisfactory, since a single ReportLab/permissions error effectively forced a full redeployment of the entire stack, despite repeated attempts to fix it in place.
Dominic König
thank you for reporting this.
Apart from the obvious permissions error (which should have been fixed by the
install-script, actually), it appears that the main issue was a corrupted
ReportLab library.
ReportLab is, in theory, an optional dependency of Eden - but in reality, most
deployments will require it, as generating PDF documents often is a mission-
critical feature. ReportLab is professionally maintained, widely used in the
Python world, and proven to be reliable throughout all these years. That said,
it does have its peculiarities that can, at times, be difficult to figure out.
Let me add two facts to the picture:
1) Since you're saying that a complete re-deployment resolves the issue with
ReportLab, the question arises what caused a corrupted ReportLab in the first
place. The cause of the problem persisted, even during a re-installation of
the library, which suggests that the ReportLab setup has side-effects beyond
the immediate library.
2) We did find a second pip-installed ReportLab during our investigation, which
did not originate from the Eden install (as that installs the distro packages
with apt-get) - and which might have been of a later version.
---
One could suspect that the cross-installation of multiple versions may have
corrupted certain files or paths involved with ReportLab, which could then not
be removed by the subsequent uninstall-/reinstall-attempts, leaving behind a
corrupted environment that could not be fixed. Re-installing the entire stack,
on the other hand, would remove them and therefore work.
This is, of course, a vague and unproven idea, but it suggests a possible way
reproduce the original problem - and, if it turns out to be the cause, it also
proposes a possible adjustment to the install-script, namely, to make sure
that there is no reportlab installed before attempting the apt installation.
Would you be willing to investigate that, and then follow up here on the
outcome?
Dominic
söndag 14 september 2025 12:55:40 CEST skrev 'Oskar Laubsch' via Eden ASP:
> Hello everyone,
>
> We recently encountered a persistent issue while deploying Eden under
> uWSGI. The application started throwing 500 errors, and instead of showing
> attempt to render a ticket resulted in another ticket being created, which
> also could not be written, and the loop repeated indefinitely.
>
> During troubleshooting together with Dominic, we identified that the
> problem was related to filesystem permissions and ReportLab. The Eden
> process was running as the web2py user, but directories such as
> applications/eden/errors, sessions, uploads, etc. were root-owned,
> preventing the application from writing tickets. At the same time,
> ReportLab failed at startup in rl_config.py with a FileNotFoundError,
> because it could not resolve $HOME or create .reportlab_settings.
>
> We tried multiple approaches: fixing ownership with chown -R web2py:web2py,
> adjusting directory permissions, manually creating .reportlab_settings,
> forcing HOME=/home/web2py in the uwsgi.ini, reinstalling ReportLab both via
> apt and pip, and even testing different versions (3.5.x vs 3.6.x).
>
> Despite these attempts, the issue persisted and the environment remained
> unstable. The only workaround we found that avoided a full reinstall was to
> completely disable ReportLab — but that meant losing all PDF generation
> functionality. In the end, the only way to move forward was to completely
> reinstall the environment — web2py, Eden, PostgreSQL, and dependencies —
> from scratch.
>
> The outcome was unsatisfactory, since a single ReportLab/permissions error
> effectively forced a full redeployment of the entire stack, despite
> repeated attempts to fix it in place.
>
> You received this message because you are subscribed to the Google Groups
"Eden
> ASP" group. To unsubscribe from this group and stop receiving emails from
it,
> send an email to eden-asp+u...@googlegroups.com. To view this
> discussion visit
> https://groups.google.com/d/msgid/eden-asp/bf72b5ba-8b7f-4920-a28e-5884c44382b
> fn%40googlegroups.com.