Pablo Moreno

I have run: ``` galaxy@galaxy-dev-job-0-6c8f594ff5-cwzd9:/galaxy/server$ bash scripts/maintenance.sh --no-dry-run --days 1 ``` inside the job container, but I get this failure: ``` galaxy@galaxy-dev-job-0-6c8f594ff5-cwzd9:/galaxy/server$ bash scripts/maintenance.sh Unsetting $PYTHONPATH Activating virtualenv at .venv...

However, even after running the subsequent step to the failing one (plus all others that run before), the disk usage in the database is more less the same...

Main culprit seems to be: ``` table_schema | table_name | total_size | data_size | external_size --------------+-------------------------------------+------------+-----------+--------------- public | history_dataset_association_history | 1193 MB | 936 kB | 1192 MB public |...

> But I think we should include this script as well. Agreed, will look to where it should go. > I think that the silent job failure should be reported...

So, for the record here, changing `.Values.postgresql.persistence.size` meant that the operator attempted a live resize of the disk, which corrupted it :-( and meant that I had to redo the...

Also, I was told by Nicola I think that the `scripts/maintenance.sh --no-dry-run` doesn't actually attempt to delete anything on the database, so there must be another mechanism.

Well the HDF5 operations have been happening before on that same container runtime, so I suspect it a general issue on lack of locks rather than specific to HDF5 (if...

I'm also putting the mulled lock_dir in a local directory of the container (I presume it won't use too much space, correct?) as suggested by Marius on Gitter.

Having mulled lock dir in a local directory also **seems** to speed up initial provisioning of jobs. I used to sometimes see the job handler log stuck in that operation...

So in my current setup I left it here: ``` mulled_resolution_cache_lock_dir: /galaxy/server/local_mulled_cache ``` are yo happy with that location? should we have perhaps a `/galaxy/server/local` directory where we move stuff...