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