Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSError: [Errno 30] Read-only file system when Chainlit tries to delete .files directory in Kubernetes deployment #1457

Open
rohanbalkondekar opened this issue Oct 22, 2024 · 0 comments
Labels
bug Something isn't working enhancement New feature or request needs-triage

Comments

@rohanbalkondekar
Copy link

Is your feature request related to a problem? Please describe.

I'm experiencing an issue when deploying a Chainlit app on Kubernetes. Our file system is read-only for security reasons, except for specific directories marked as emptyDir in the Kubernetes YAML configuration. The application attempts to delete the .files directory located at /code/app/.files during startup. Since the parent directory /code/app is read-only, this operation fails with the following error:

OSError: [Errno 30] Read-only file system: '/code/app/.files'

This prevents the application from starting properly.

Describe the solution you'd like

I would like the ability to configure the location of the .files directory to a different path that resides in a writable location. This could be achieved by allowing a configuration option in Chainlit to specify an alternative path for the .files directory.

Describe alternatives you've considered

  • Changing the Kubernetes Configuration: Adjusting the Kubernetes YAML to make the parent directory /code/app writable is not feasible due to security policies.
  • Symlinking: Creating a symbolic link from /code/app/.files to a writable directory, but this approach is also hindered by the read-only nature of the parent directory.
  • Modifying Chainlit Source Code: Altering the source code of Chainlit to change the path of the .files directory, but this is not ideal for maintainability and future updates.

Additional context

Here is the relevant portion of my Kubernetes YAML configuration:

emptyDirs:
  enabled: true
  volumes:
    - name: results
      path: /src/results
    - name: files
      path: /code/app/.files
    - name: var-tmp
      path: /var/tmp
    - name: run
      path: /run
    - name: chainlit-config
      path: /code/app/.chainlit

As you can see, /code/app/.files is marked as an emptyDir, which should allow write access within .files. However, since /code/app is read-only, deleting the .files directory fails during the application's startup lifespan.

Error Log:

=========================
Chainlit App Started
=========================
2024-10-22 06:10:13 - FastAPI Backend URL: http://aero-datascience-genai-checkin-service:8000/chat
2024-10-22 06:10:13 - Your app is available at http://localhost:5050
ERROR:    Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/starlette/routing.py", line 741, in lifespan
    await receive()
  File "/usr/local/lib/python3.9/contextlib.py", line 188, in __aexit__
    await self.gen.__anext__()
  File "/usr/local/lib/python3.9/site-packages/fastapi/routing.py", line 138, in merged_lifespan
    yield {**(maybe_nested_state or {}), **(maybe_original_state or {})}
  File "/usr/local/lib/python3.9/contextlib.py", line 188, in __aexit__
    await self.gen.__anext__()
  File "/usr/local/lib/python3.9/site-packages/chainlit/server.py", line 150, in lifespan
    shutil.rmtree(FILES_DIRECTORY)
  File "/usr/local/lib/python3.9/shutil.py", line 740, in rmtree
    onerror(os.rmdir, path, sys.exc_info())
  File "/usr/local/lib/python3.9/shutil.py", line 738, in rmtree
    os.rmdir(path)
OSError: [Errno 30] Read-only file system: '/code/app/.files'

ERROR:    Application shutdown failed. Exiting.

Question:

Is there a way to configure Chainlit to use a different directory for .files that is in a writable location? Alternatively, can Chainlit avoid attempting to delete the .files directory at startup if it's not necessary?

@dosubot dosubot bot added bug Something isn't working enhancement New feature or request labels Oct 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request needs-triage
Projects
None yet
Development

No branches or pull requests

1 participant