Files associated with deleted sources not deleted in dev env #4328
Labels
Comments
rmol
added a commit
to rmol/securedrop
that referenced
this issue
Apr 29, 2019
To ensure asynchronous processes like submission deletion and hashing happen in dev containers, run supervisord and our rq worker. This adds a "run_supervisor" function in dev-deps that creates a supervisor config under /tmp (which just runs the rq worker), and starts supervisor. That function is now invoked in securedrop/bin/run. The Dockerfiles now install supervisor via pip or pip3. Fixes freedomofpress#4328.
1 task
kushaldas
pushed a commit
that referenced
this issue
Sep 25, 2019
To ensure asynchronous processes like submission deletion and hashing happen in dev containers, run supervisord and our rq worker. This adds a "run_supervisor" function in dev-deps that creates a supervisor config under /tmp (which just runs the rq worker), and starts supervisor. That function is now invoked in securedrop/bin/run. The Dockerfiles now install supervisor via pip or pip3. Fixes #4328.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
In the development environment, if you delete a source (as a collection, or individual submissions), the associated files are never deleted from
/var/lib/securedrop/store.Steps to Reproduce
make devinsecuredropdirectory;Expected Behavior
Source metadata and all associated files in
/var/lib/securedrop/storeare deleted.Actual Behavior
Source metadata appears to be deleted; files in
/var/lib/securedrop/storeare not.redis-cli monitorshows the job being enqueued, but it is never picked up.Logs also show a GPG-related exception when deleting a source, which is tracked as #4294.
Comments
@kushaldas and I have been unable to replicate this bug in a staging environment (Kushal tested with the
pyy3branch, I tested withdevelop); it appears to be dev env only.The text was updated successfully, but these errors were encountered: