Menu

#144 JOC startup log4j2 error: parent directory /var/sos-berlin.com/js7/logs is not created by installer

2.8
open
nobody
None
5
2026-07-07
2026-07-07
Xenbeat
No

Hello,

After a fresh install of JOC Cockpit 2.8.3 on Ubuntu 24.04, we see a
log4j2 ERROR line at every startup because the parent directory of
service-reports.log (/var/sos-berlin.com/js7/logs) does not exist and
cannot be auto-created by the runtime user. We would appreciate your
advice on how to handle this cleanly.

Environment

  • JS7 JOC Cockpit: 2.8.3
  • OS: Ubuntu 24.04.3 LTS
  • Java: OpenJDK 21.0.11
  • PostgreSQL: 17
  • Install script arguments:

    js7_install_joc.sh \
    --release=2.8.3 \
    --home=/opt/sos-berlin.com/js7/joc \
    --data=/var/sos-berlin.com/js7/joc \
    --user=scheduler \
    --home-owner=root:scheduler \
    --data-owner=scheduler:scheduler \
    --service-name=js7_joc \
    --http-port=4446 \
    --title="Primary JOC Cockpit" \
    --security-level=medium \
    --dbms-config=/path/to/hibernate.cfg.xml \
    --as-user \
    --force-sudo \
    --make-dirs \
    --make-service \
    --exec-start=StartService

Symptom

The following ERROR line appears in /var/log/sos-berlin.com/js7/joc/jetty.log
on every startup:

2026-07-06T08:52:33.666Z main ERROR Unable to create file
/var/sos-berlin.com/js7/joc/../logs/service-reports.log
java.io.IOException: Could not create directory
/var/sos-berlin.com/js7/logs
    at org.apache.logging.log4j.core.util.FileUtils.mkdir(FileUtils.java:129)
    at org.apache.logging.log4j.core.util.FileUtils.makeParentDirs(FileUtils.java:143)

What we observed

The log4j2 appender path resolves to
/var/sos-berlin.com/js7/logs/service-reports.log (one level above the JOC
data directory).

The parent /var/sos-berlin.com/js7/ is created by the install script with
root:root and mode 755:

$ ls -la /var/sos-berlin.com/
drwxr-xr-x 4 root root 4096 Jun 25 18:55 js7

So the JOC process (running as the runtime user "scheduler") does not
have permission to create /var/sos-berlin.com/js7/logs at that location.
The install script does not create this directory either.

The per-service logs directory /var/sos-berlin.com/js7/joc/logs is
correctly created as a symlink to /var/log/sos-berlin.com/js7/joc.

Workaround we currently apply

mkdir -p /var/sos-berlin.com/js7/logs
chown scheduler:scheduler /var/sos-berlin.com/js7/logs
chmod 755 /var/sos-berlin.com/js7/logs
systemctl restart js7_joc

After this, the ERROR line no longer appears in jetty.log.

Questions

  1. Is /var/sos-berlin.com/js7/logs intended to be created manually by
    the operator after install, or is the install script expected to
    create it? If manual creation is intended, is there a recommended
    ownership / permissions?

  2. Is this shared logs directory meant to be shared across JOC /
    Controller / Agent instances on the same host? We would like to
    understand the intended layout to prepare it consistently.

  3. Are there any operational implications of the ERROR line being
    present at startup?

Any guidance you can share would be much appreciated.

Best regards

Discussion

  • Andreas

    Andreas - 2026-07-07

    Hi,
    the warning is due to an bug in the log4j2.xml configuration file available from the <jetty-base>/resouces/joc directory that holds the line
    filePattern="${sys:user.dir}/../logs/service-reports-%d{yyyy-MM-dd}-%i.log.gz"
    which should be
    filePattern="${sys:user.dir}/logs/service-reports-%d{yyyy-MM-dd}-%i.log.gz"

    The message that you find in jetty.log is not harmful though it is qualified an ERROR. The indicated log file is used by the reporting feature that changes its working directory at run-time. This has been fixed for upcoming 2.8.4 and 2.9.0 releases.

    Your solution is viable as it prevents the error and keeps the reporting feature working.

     
  • Xenbeat

    Xenbeat - 2026-07-07

    Hi,

    Thank you very much for the clear explanation.

    We will continue with the workaround until we upgrade to 2.8.4 or
    2.9.0, at which point the source-level fix will remove the need for it.

    This is fully resolved for us. We will close this ticket.

    Thank you again for the prompt and detailed response.

    Best regards

     

Log in to post a comment.