I try to migrate from DSpace 6.4 to 7.1. New Dspace is installed on other machine (virtual machine on Centos 7 with 8Gb of RAM)
I have created full site AIP backup with user passwords. (total size of packages - 11Gb)
I've tried to do full restore but always got the same error.
So I'm just trying to import only "first level without childs"
JAVA_OPTS="-Xmx2048m -Xss4m -Dfile.encoding=UTF-8" /dspace/bin/dspace packager -r -k -t AIP -e dinkwi.test#gmail.com -o skipIfParentMissing=true -i 123456789/0 /home/dimich/11111/repo.zip
It doesn't matter if I use -k or -f param, output ia always the same
Ingesting package located at /home/dimich/11111/repo.zip
Exception: null
java.lang.StackOverflowError
at org.dspace.eperson.GroupServiceImpl.getChildren(GroupServiceImpl.java:788)
at org.dspace.eperson.GroupServiceImpl.getChildren(GroupServiceImpl.java:802)
.... (more then 1k lines)
at org.dspace.eperson.GroupServiceImpl.getChildren(GroupServiceImpl.java:802)
my dspace.log ended with
2021-12-20 11:05:28,141 INFO unknown unknown org.dspace.eperson.GroupServiceImpl # dinkwi.test#gmail.com::update_group:group_id=9e6a2038-01d9-41ad-96b9-c6fb55b44381
2021-12-20 11:05:30,048 INFO unknown unknown org.dspace.eperson.GroupServiceImpl # dinkwi.test#gmail.com::update_group:group_id=23aaa7e9-ca2d-4af5-af64-600f7126e2be
2021-12-20 11:05:30,800 INFO unknown unknown org.springframework.cache.ehcache.EhCacheManagerFactoryBean # Shutting down EhCache CacheManager 'org.dspace.services'
So I just want to figure out the problem: small stack or some bug in user/group that fails with infinite loop/recursion, or maybe something else...
Main problem - i'm good in php/mysql and have no experience with java/postgre and the way how to debug this ...
Any help would be appreciated.
p.s after failed restore I always run command
/dspace/bin/dspace cleanup -v
Related
Having great difficulty tracking down what is causing the below error when attempting to update any package from any repo. I have tested multiple repos by setting all others to disabled. I have cleaned all cache and removed any dnf yum cache files.
# dnf -v update
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync
DNF version: 4.2.7
cachedir: /var/cache/dnf
repo: downloading from remote: AppStream
error: Curl error (28): Timeout was reached for http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock [Resolving timed out after 30000 milliseconds] (http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock).
CentOS-8 - AppStream 0.0 B/s | 0 B 00:30
Cannot download 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock [Resolving timed out after 30000 milliseconds].
Failed to download metadata for repo 'AppStream'
Error: Failed to download metadata for repo 'AppStream'
Each time I attempt a dnf update, load average on the server goes thru the roof, up to 40x
curl can access the mirror site.
curl 'http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=stock'
http://ftp.tc.edu.tw/Linux/CentOS/8.2.2004/AppStream/x86_64/os/
http://mirror.horizon.vn/centos/8.2.2004/AppStream/x86_64/os/
http://ftp.jaist.ac.jp/pub/Linux/CentOS/8.2.2004/AppStream/x86_64/os/
http://centosg9.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://packet01.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://mirror.s8.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centoso7.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosh9.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosc8.centos.org/centos/8.2.2004/AppStream/x86_64/os/
http://centosg7.centos.org/centos/8.2.2004/AppStream/x86_64/os/
I have also tried using baserurl in .repo, same error
I have also replaced the baseurl with one of the url's returned by curl, same error
I have tried many suggestions such as yum/dnf error: Failed to download metadata for repo
and similar, none work for me.
Some articles point to bugs in the env vars for $releaseserver etc. I have also tried replacing with actual values. same error.
Internet connection obviously OK due to curl result.
No proxy used.
DNS OK
cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)
uname -a
Linux xxxx 4.18.0-147.5.1.el8_1.x86_64 #1 SMP Wed Feb 5 02:00:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Any suggestions would be greatly appreciated.
For some weird reasons, After setting the nameserver in /etc/resolv.conf to 8.8.8.8 and a reboot fixed the problem for me.
Also, I disabled the Dynamic memory for Hyper-V VM. DNF command is expecting a lot of memory.
Please give it a try.
Regards,
Arockiasamy
The only thing that worked for me was to disable and remove the offending repo.
sudo yum --disablerepo=epel\* remove epel-release.noarch
I am trying to start busybox container as non root on CentOS 8 server, but its giving the below message.
What is the correct way to start the container as non-root user?
podman run -it --name busy docker.io/library/busybox sh
Trying to pull docker.io/library/busybox...Getting image source signatures
Copying blob bdbbaa22dec6 done
Copying config 6d5fcfe5ff done
Writing manifest to image destination
Storing signatures
ERRO[0003] Error pulling image ref //busybox:latest: Error committing the finished image: error adding layer with blob "sha256:bdbbaa22dec6b7fe23106d2c1b1f43d9598cd8fc33706cc27c1d938ecd5bffc7": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 65534:65534 for /home): lchown /home: invalid argument
Failed
Error: unable to pull docker.io/library/busybox: unable to pull image: Error committing the finished image: error adding layer with blob "sha256:bdbbaa22dec6b7fe23106d2c1b1f43d9598cd8fc33706cc27c1d938ecd5bffc7": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 65534:65534 for /home): lchown /home: invalid argument
Yes, the command you run is correct. On my Fedora 31 system it works just fine.
[testuser#fedora31 ~]$ podman run -it --name busy docker.io/library/busybox sh
Trying to pull docker.io/library/busybox...
Getting image source signatures
Copying blob bdbbaa22dec6 done
Copying config 6d5fcfe5ff done
Writing manifest to image destination
Storing signatures
/ # exit
[testuser#fedora31 ~]$ podman --version
podman version 1.8.0
[testuser#fedora31 ~]$
The flag --rm is also often useful.
It seems the error you get is related to the UID mapping.
Here is some information regarding running "rootless" podman:
https://github.com/containers/libpod/blob/master/docs/tutorials/rootless_tutorial.md
What also might be interesting:
"Does not work on NFS or parallel filesystem homedirs"
Quote from
https://github.com/containers/libpod/blob/master/rootless.md
I am trying to start minishift on my machine. It successfully creates minishift VM but throws time out error.
Configuration:
Minishift version: v1.34.0+f5db7cb
OS: Windows 10
Hypervisor: Virtual Box v6.0.10
PS C:\WINDOWS\system32> minishift start
-- Starting OpenShift cluster .......................................................................Error during 'cluster up' execution: Error starting the cluster. ssh command error:
command : /var/lib/minishift/bin/oc cluster up --image 'openshift/origin-${component}:v3.11.0' --public-hostname 192.168.99.100 --routing-suffix 192.168.99.100.nip.io --base-dir /var/lib/minishift/base
err : exit status 1
output : Getting a Docker client ...
Checking if image openshift/origin-control-plane:v3.11.0 is available ...
Pulling image openshift/origin-cli:v3.11.0
E0725 17:15:42.919928 5316 helper.go:173] Reading docker config from /home/docker/.docker/config.json failed: open /home/docker/.docker/config.json: no such file or directory, will attempt to pull image docker.io/openshift/origin-cli:v3.11.0 anonymously
Image pull complete
E0725 17:15:44.643860 5316 helper.go:173] Reading docker config from /home/docker/.docker/config.json failed: open /home/docker/.docker/config.json: no such file or directory, will attempt to pull image docker.io/openshift/origin-node:v3.11.0 anonymously
Pulling image openshift/origin-node:v3.11.0
Pulled 5/6 layers, 85% complete
Pulled 6/6 layers, 100% complete
Extracting
Image pull complete
Checking type of volume mount ...
Determining server IP ...
Using public hostname IP 192.168.99.100 as the host IP
Checking if OpenShift is already running ...
Checking for supported Docker version (=>1.22) ...
Checking if insecured registry is configured properly in Docker ...
Checking if required ports are available ...
Checking if OpenShift client is configured properly ...
Checking if image openshift/origin-control-plane:v3.11.0 is available ...
I0725 17:16:20.775520 5316 config.go:40] Running "create-master-config"
Starting OpenShift using openshift/origin-control-plane:v3.11.0 ...
I0725 17:16:31.108342 5316 config.go:46] Running "create-node-config"
I0725 17:16:35.237968 5316 flags.go:30] Running "create-kubelet-flags"
I0725 17:16:36.785234 5316 run_kubelet.go:49] Running "start-kubelet"
I0725 17:16:37.288388 5316 run_self_hosted.go:181] Waiting for the kube-apiserver to be ready ...
E0725 17:21:37.300062 5316 run_self_hosted.go:571] API server error: Get https://192.168.99.100:8443/healthz?timeout=32s: dial tcp 192.168.99.100:8443: connect: connection refused ()
Error: timed out waiting for the condition
Expected result: It should provide me without errors link to open web console
This happens to me sometimes too.
Solutions include:
minishift stop && minishift start (turn it off and on again)
restart Windows (perhaps VBox has corrupted itself again)
More info on my minishift setup is here:
http://divby0.blogspot.com/2019/07/configuring-minishift-for-use-with.html
For what it's worth I use a combination of linux shells in Windows 10 to interact with minishift / docker daemon:
Git Bash (usually the best)
Docker Toolbox (plan B when something won't run in Git Bash shell)
WSL (ubuntu based, plan C in desperation)
I am setting up Solr for Centos 7. When i try to execute any sample project for ex. using ./bin/solr start -e techproducts, its throwing error of 'Exception : org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)' . How to fix this. Java is installed under '/usr/bin/java'
I tried with changing Java home directory path
./bin/solr start -e techproducts
*** [WARN] *** Your Max Processes Limit is currently 31165.
It should be set to 65000 to avoid operational disruption.
If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh
Solr home directory /tmp/solr-7.7.2/example/techproducts/solr already exists.
Starting up Solr on port 8983 using command:
"bin/solr" start -p 8983 -s "example/techproducts/solr"
*** [WARN] *** Your Max Processes Limit is currently 31165.
It should be set to 65000 to avoid operational disruption.
If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false in your profile or solr.in.sh
WARNING: Starting Solr as the root user is a security risk and not considered best practice. Exiting.
Please consult the Reference Guide. To override this check, start with argument '-force'
ERROR: Failed to start Solr using command: "bin/solr" start -p 8983 -s "example/techproducts/solr" Exception : org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
Credit for the answer should go to #MatsLindh (see comment above). I'm adding it here for others who may experience the same problem.
The issue is that Solr doesn't want you to run it as a root user - or what it thinks is a root user (I've seen this issue with WSL as well and one isn't running as root).
Using root is a security risk but you can force Solr to start anyways by adding -force to the command, for example:
bin/solr start -e cloud -force
I have a freshly installed Koha 3.16 in a Debian Server. I already imported the MARC records into the catalog, but when I search it on Opac , there is no results found.
I read this link: My Zebra Indexing won’t work! How do I fix it? (AKA: I search for stuff and nothing comes up! Help!)
I have tried to follow what has been said in this link. But unfortunately Im stuck with the third step.
export PERL5LIB=/usr/share/koha/lib
export KOHA_CONF=/usr/share/koha/koha-conf.xml
/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x
I run this commands, but still, no luck. I tried to rebuild zebra using the command:
sudo koha-rebuild-zebra -f -v mylibrary
The result shows:
Zebra configuration information
================================
Zebra biblio directory = /var/lib/koha/mylibrary/biblios
Zebra authorities directory = /var/lib/koha/mylibrary/authorities
Koha directory = /usr/share/koha/intranet/cgi-bin
Lockfile = /var/lock/koha/mylibrary/rebuild/rebuild..LCK
BIBLIONUMBER in : 999$c
BIBLIOITEMNUMBER in : 999$d
================================
skipping authorities
====================
exporting biblio
====================
Records exported: 7922
====================
REINDEXING zebra
====================
18:04:12-13/11 zebraidx(8862) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/norm..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8862) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/shadow..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8862) [fatal] Could not select database biblios errCode=109
18:04:12-13/11 zebraidx(8863) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/norm..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8863) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/shadow..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8863) [fatal] Could not select database biblios errCode=109
====================
CLEANING
====================
Zebra configuration information
================================
Zebra biblio directory = /var/lib/koha/mylibrary/biblios
Zebra authorities directory = /var/lib/koha/mylibrary/authorities
Koha directory = /usr/share/koha/intranet/cgi-bin
Lockfile = /var/lock/koha/mylibrary/rebuild/rebuild..LCK
BIBLIONUMBER in : 999$c
BIBLIOITEMNUMBER in : 999$d
================================
====================
exporting authority
====================
Records exported: 0
====================
REINDEXING zebra
====================
skipping biblios
====================
CLEANING
====================
Whats wrong with reindexing Zebra? How will I fix it? I found a problem same with me, but honestly I dont get how to apply a Patch.Here's the link:
zebraidx errCode=109
Please fix it. I really have to get this working.
Happened the same when install koha in Centos. Try:
Koha-rebuild-zebra -f -v -b mylibrary
You can use these lines to restart the search tables.
sudo zebraidx -c /etc/koha/sites/library/zebra-biblios.cfg drop biblios
sudo zebraidx -c /etc/koha/sites/library/zebra-biblios.cfg commit
koha-rebuild-zebra -b -r -v mylibrary
Finally: Try to change the parameter SearchEngine in the preferences section. Zebra to Solr.
Other parameters (source):
-f, --full Does a reindex of the whole collection. Will run even if USE_INDEXER_DAEMON=yes.
-a, --authorities Only run the indexing process for authority records.
-b, --biblios Only run the indexing process for biblio records.
-q, --quiet Sometimes be a bit quieter for scripts/cronjobs.
-v, --verbose Be verbose. Useful for debugging indexing problems.
Hi your all previous step looks great
after all the above steps as followed by user till /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x looks fine
after that you give the following command
zebrasrv -f /path/to/the.KOHA_CONF file i.e xml file which should run in background process else if you get logout indexing also go off
I have a similar problem, zebraserv seems to exit randomly. The log is not much help, as it does not capture what caused the crash. The symptom is that searches don't work. I found that restarting koha fixes the issue. However restarting all the time is not ideal. Some investigation on my system ( Debian 8.3 with Koha 16.05.05.000 ) reveal that the zebraserv process dying is a symptom of the issue. I wrote this script to be run as a cron job ( for root ) that runs every 60 seconds. This appears to make it recover. It seems to happen once every few days.
This has been happening in the last few releases of koha-common via Debian apt-get
I called it /root/check_zebra.sh ..... it is
:
# Add this to cron i.e ( remove the leading "#" ) for root
# * * * * * /root/check_zebra.sh >> /root/check_zebra.log
#
ps ax | grep zebrasrv | grep koha-conf.xml > /dev/null
status=$?
if [ $status = "0" ]
then
:
else
# Restart
echo "============================================="
date
echo "zebrasrv has stopped. Restarting Koka..."
echo "/etc/init.d/koha-common restart"
/etc/init.d/koha-common restart
fi