This is a regression introduced in artefactual-labs/ansible-archivematica-src#425 (commit artefactual-labs/ansible-archivematica-src@8724e36).
At start-up, Gunicorn adds the "application directory" to the Python search path (see https://github.com/benoitc/gunicorn/blob/23.0.0/gunicorn/app/base.py#L88). This directory is set from the chdir configuration option, and defaults to the current working directory.
Since the chdir option is not used in the ansible installation scripts, the CWD is used. The commit referenced above removed the WorkingDirectory setting from the SystemD service file, which defaults to the root directory.
What this means is that the root directory is now in the search path for Python modules, and if a top-level directory is found with the same name as one of the Archivematica modules, this directory is used instead of the actual source directory. To make things worse, the lack of a __init__.py file results in the directory being treated as a namespace package, with very confusing results.
I experienced this exact problem with a client installation, where the data for the Storage Service is located in /archivematica/storage_service, causing the following error:
Apr 24 20:58:27 xxx gunicorn[2929970]: Failed to read config file: /etc/archivematica/storage-service.gunicorn-config.py
Apr 24 20:58:27 xxx gunicorn[2929970]: TypeError: expected str, bytes or os.PathLike object, not NoneType
The error is raised from line 11 in the default config file:
storage_service_path = str(importlib.resources.files("archivematica.storage_service"))
Steps to reproduce
mkdir -p /archivematica/storage_service
systemctl restart archivematica-storage-service.service
Your environment (version of Archivematica, operating system, other relevant details)
AM 1.18.0 on Debian 13 (Trixie)
Workaround
A simple workaround is to re-establish the missing WorkingDirectory parameter:
# mkdir -p /etc/systemd/system/archivematica-dashboard.service.d
# mkdir -p /etc/systemd/system/archivematica-storage-service.service.d
# echo -e '[Service]\nWorkingDirectory=/usr/share/archivematica/' | \
tee /etc/systemd/system/archivematica-dashboard.service.d/override.conf
# echo -e '[Service]\nWorkingDirectory=/usr/share/archivematica/' | \
tee /etc/systemd/system/archivematica-storage-service.service.d/override.conf
# systemctl daemon-reload
For Artefactual use:
Before you close this issue, you must check off the following:
This is a regression introduced in artefactual-labs/ansible-archivematica-src#425 (commit artefactual-labs/ansible-archivematica-src@8724e36).
At start-up, Gunicorn adds the "application directory" to the Python search path (see https://github.com/benoitc/gunicorn/blob/23.0.0/gunicorn/app/base.py#L88). This directory is set from the
chdirconfiguration option, and defaults to the current working directory.Since the
chdiroption is not used in the ansible installation scripts, the CWD is used. The commit referenced above removed theWorkingDirectorysetting from the SystemD service file, which defaults to the root directory.What this means is that the root directory is now in the search path for Python modules, and if a top-level directory is found with the same name as one of the Archivematica modules, this directory is used instead of the actual source directory. To make things worse, the lack of a
__init__.pyfile results in the directory being treated as a namespace package, with very confusing results.I experienced this exact problem with a client installation, where the data for the Storage Service is located in
/archivematica/storage_service, causing the following error:The error is raised from line 11 in the default config file:
Steps to reproduce
Your environment (version of Archivematica, operating system, other relevant details)
AM 1.18.0 on Debian 13 (Trixie)
Workaround
A simple workaround is to re-establish the missing
WorkingDirectoryparameter:For Artefactual use:
Before you close this issue, you must check off the following: