Bug#956464: solr-tomcat: Unable to perform replication as slave
Andy Beverley
andy at andybev.com
Sat Apr 11 18:00:58 BST 2020
Package: solr-tomcat
Version: 3.6.2+dfsg-20+deb10u1
Severity: normal
Dear Maintainer,
Solr running under Tomcat is unable to perform replication as a slave.
This is because during replication it tries to create a temporary
directory within its configuration directory (normally /etc/solr/conf,
but could also be others if running multiple cores).
The problem is the same as that fixed in #919638, which is that even
if write permissions are temporarily given to that directory (as I have
done on previous systems) the sandbox still does not allow write access.
This is made worse by the poor error message that solr gives (not
specifying the error or full path). A day of debugging and rebuilding
the application was required to work out the cause!
I fixed the problem by adding the path to solr-permissions.conf as
below.
-- System Information:
Debian Release: 10.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages solr-tomcat depends on:
ii solr-common 3.6.2+dfsg-20+deb10u1
ii tomcat9 9.0.16-4
solr-tomcat recommends no packages.
solr-tomcat suggests no packages.
-- Configuration Files:
/etc/systemd/system/tomcat9.service.d/solr-permissions.conf changed:
[Service]
ReadWritePaths=/var/lib/solr/
ReadWritePaths=/etc/solr
-- no debconf information
More information about the pkg-java-maintainers
mailing list