Where the logs go

The log directory is arcadedb/log under your state directory:

When the directory cannot be created or written, the package logs a warning and uses a new arcadedb-log-* directory under the system temp directory.

The directory holds the engine log (arcadedb.log.0, arcadedb.log.1 and so on, up to 10 files of 100 MB), and the logging configuration that the package writes for the engine (logging.properties, or logging-file-only.properties when the console is off, see below). The arcadedb-jvm package also keeps the JVM crash file hs_err_pid<pid>.log there.

The engine logs to its file and, on Linux and macOS, to the console too (stderr). On Windows the console log is off by default: the log goes to the file only.

The reason is a Windows detail. The runtime saves the OS handle of stdout and stderr when it starts. If your program redirects file descriptor 1 or 2 later (pytest’s default output capture does this around every test, and so can a service or an application that embeds the library), Windows closes that handle and can give the same handle value to the next file that is opened, for example a database file. The next console log line is then written into that database file and corrupts it. The log file does not have this problem, because the engine opens it itself.

Set ARCADEDB_LOG_CONSOLE before the first database is opened to choose on any platform:

1, true, yes and on turn the console log on, 0, false, no and off turn it off. Any other value, and no value, gives the platform default above. The package writes the configuration without the console handler to logging-file-only.properties in the log directory, so processes with different settings that share a directory do not replace each other’s file.

A java.util.logging.config.file that you set yourself (see below) replaces all of this: its handlers decide where the log goes.

Log lines are not the only text the runtime writes through that handle: a warning a library prints, or a printed stack trace, goes to Java’s System.out or System.err, and the runtime’s own warnings go to a copy of System.err that System.setErr does not change. One of them is the warning that the runtime prints once, when the first vector index is reopened (A terminally deprecated method in sun.misc.Unsafe has been called, from the jvector library; JEP 498). Neither package lets that warning appear: the arcadedb-jvm package starts the JVM with --sun-misc-unsafe-memory-access=allow (a value of your own in jvm_args or ARCADEDB_JVM_ARGS wins), and the native image of the arcadedb package is built with the same option, which is fixed in the image and cannot be changed at run time. In the arcadedb-jvm package, for any other text of this kind, with the console off (the default on Windows, or ARCADEDB_LOG_CONSOLE=0), the package therefore points all three at arcadedb-stdio.log in the log directory, a file that it opens itself, right after the JVM starts. The runtime’s own start-up warning (WARNING: Using incubator modules: jdk.incubator.vector) is printed while the JVM is created, before the package can do this, and still goes to the stderr of your process. With ARCADEDB_LOG_CONSOLE=1 on Windows, System.out and System.err keep the runtime’s handle, so the risk above stays: do not redirect fd 1 or 2 after the first database is opened.

The packages themselves never print to the console on Windows: the glue code of the native build logs through the same engine log instead of writing to stderr.

Set ARCADEDB_LOG_DIR before the first database is opened. The first call that starts the engine reads it, so setting it later has no effect in the same process.

The packages pass two Java system properties to the engine: arcadedb.server.logsDirectory (the directory) and java.util.logging.config.file (the logging.properties in it). If you set one of them yourself, yours is kept and the other default still applies.