I am running my small galaxy server for my research group, and so far it was running fine.
We are using MACS2 for peak calling, and it was working fine for half a year now. However, since today it has issues. When called, I get the error:
Traceback (most recent call last):
File "/home/galaxy/galaxy/database/dependencies/_conda/envs/mulled-v1-63b8564a14cbab46411574254eddbb325c65705c3efeaf309fd24f85f88f7658/bin/macs2", line 23, in <module>
from MACS2.Constants import *
ModuleNotFoundError: No module named 'MACS2'
If I activate the environment on the bash, I can run MACS2. I removed MACS2 already via the user interface, and also removed the conda environment manually. Restarted the server. Installed older versions of MACS2 and running those. Nothing really helped. I don’t understand why this tool stopped working from one day to the other. We applied changes only on runners limits the last days, and after those were active it was also still working.
From what I understand googling this error, it is that the imports are not seen by MACS2, but why should this be the case? The environment seems to be activated correctly, otherwise why do I get in the error the full path to the environment? And why do also older versions do not run and crash with the same error?
All other tools I tested so far are still running.
What data can I provide to help you to understand better what might be the issue?
I am a bit out of ideas, maybe someone here has an idea on how to solve this?
Very strange! I’ve cross posted your question over to our Admins chat group to see if anyone has ideas about how to help. They may reply here or there, and free to join the chat. You're invited to talk on Matrix
Meanwhile, if you could post back some of the larger specifications for your server that will likely add some context. Versions of: the Galaxy application, your system OS, Python, and anything else that seems relevant. When I’ve seen ModuleNotFoundError resolved before, it involved fixing a Python version conflict inside of the container running the job (via the mulled envs). That’s why the versions of what you running might matter.
I am running Ubuntu 22.04, the Galaxy version is a bit complicated. I realized too late the default branch is the dev and not the last stable release. And then we were already running it in production. Since it runs stable, we don’t see why we shall change it. Anyhow, it is something between 24.0 and 24.1 as far as I can tell. The commit is from March 13, 2024 with the hash 9a4a5bc6145e81286c77908ad02371105834c49b.
In the root environment we run Python is 3.10.13, the conda environment of MACS has 3.11.9. We run it with slurm on the same computer.
What we did short before it stopped working:
Apply limits on the runners on job_conf.yml
Installed bwameth and created indices
Installed bismark
Installed bsfcall
Installed BSMAP
Searched all the installed conda environments where bsfcall is located
