Hi Christian,

As usual, you are 100% right and you gave me the solution.

I've started it with the "nohup" command, so, in the "/bin" folder I've found the "nohup.out" file and a "hs_err_pid.log" file generated with the crash details.

You can see the full logfile from here: https://controlc.com/40a28686

But, basically, the reason was a failed memory allocation:

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 123731968 bytes for committing reserved memory.
# Possible reasons:
# The system is out of physical RAM or swap space
# The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# JVM is running with Zero Based Compressed Oops mode in which the Java heap is
# placed in the first 32GB address space. The Java Heap base address is the
# maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress
# to set the Java Heap base and to place the Java Heap above 32GB virtual address.
# This output file may be truncated or incomplete.
#
# Out of Memory Error (os_linux.cpp:2992), pid=2854, tid=2863
#
# JRE version: OpenJDK Runtime Environment (11.0.12+7) (build 11.0.12+7-post-Debian-2deb10u1)
# Java VM: OpenJDK 64-Bit Server VM (11.0.12+7-post-Debian-2deb10u1, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#

So, I'll try decreasing the Java heap size.

Thank you very very much for your help, you always save my life!!

Kind regards,

Sebastian

P/D: I owe you an Argentinian barbecue, an "asado"!!

On Thu, Nov 25, 2021 at 2:07 PM Christian Grün <christian.gruen@gmail.com> wrote:

Hi Sebastian,

how did you start the HTTP server?

If you use the basexhttp startup script from our full distributions
(ZIP, etc.), you can redirect the output to files:

$ basexhttp >basex.log 2>basex.err

This is mostly helpful for unexpected behavior, if e.g. Java is
crashing (i.e., all errors that cannot be caught by BaseX itself).

Hope this helps (...at least for the next failover),
Christian

On Thu, Nov 25, 2021 at 4:24 PM Sebastian Guerrero <chapeti@gmail.com> wrote:
>
> Hi team!
>
> I'm enjoying using BaseX more than a year ago, thank you very much for all your help.
>
> But then, suddenly, the HTTP server instance stops working while I'm executing a long time duration process: around 4 hours to generate some indexes. ( the process just crash and I have to restart it ).
>
> This process was running daily for the last 14 months, without any problem.
>
> My doubt is this: where or how may I get some information about what caused the problem?
>
> Checking files inside /data/.logs I see only the RESTXQ calls and other minor logs, but nothing to give me a clue about the reason for the server crash.
>
> I'm running BaseX 9.4 beta on a Debian machine. Here you have my settings: https://imgur.com/ucngBhY
>
> Any suggestions?
>
>