Best way to reduce Logging in dockered Openhab?

  • Platform information:

    • Hardware: NUC Intel I3 / 12 Gb
    • OS: Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-56-generic x86_64)
    • Java Runtime Environment (in docker): openjdk version “11.0.15” 2022-04-19
    • openHAB version: 3.2.0 (docker-image: openhab/openhab:3.3.0)
  • Issue of the topic: Just a question


In the past I successful reduced logging for openhabian on a RPi4. it still works but I cannot find how I did this, meaning:

  • The majority of the Logging topics are from the OH2 era and for example I know the file “org.ops4j.pax.logging.cfg” is in OH3 just the expected oneliner and moved to “log4j2.xml”.
  • However I cannot find any real explanation in the RPi4 file “log4j2.xml” for this reduced logging (both files are on my RPI4 in " /var/lib/openhab/etc/"
  • I my notes I saved an instruction to do a “log:set” in the console but if I go now on my RPi4 into the console with “ssh -p 8101 openhab@localhost” the next the command “log:list” and others commands give the error “Error executing command: Unrecognized configuration”. So this environment looks a bit shaky now, despite it seems to work, but no problem I already migrated to my NUC.


In my new situation I can find the file in “log4j2.xml” in “/opt/openhab/userdata/etc/”
My question is: Am I allowed to add directly in the appropiate section of this file the following lines?:

<Logger level="ERROR" name="openhab.event.ItemStateChangedEvent"/>
<Logger level="ERROR" name="openhab.event.ItemCommandEvent"/>
<Logger level="ERROR" name="openhab.event.ItemStatePredictedEvent"/>

Or should this been done differently?
It seems to give the desired result (active after a stop/start of the docker openhab)

Side question: Which version do I have?

  • When I do “docker exec -it openhab /openhab/runtime/bin/client” I see “3.3.0 - Release Build” (BTW when i do next log:list (a valid command in the TAB overview) the result is “Command not found: log:get”
  • but in “http://NUC-ip/about/” I see “openHAB 3.2.0”.


You could use the karaf console and, relatively recently a REST API end point was added where you can adjust the logging through the API Explorer. In both of these cases, that log4j2.xml file gets edited so you could just skip the middle man and edit the file yourself.


They should be the same. Are you certain you don’t have two separate containers running or something like that?

This points to a syntax error in your logging config or something like that. The karaf console log commands have not changed and they should still work as they always have.

1 Like

Clear, so I have several options to update “log4j2.xml”. main question solved.

My side-problem is caused by a restore from a backup of my RPi4 which was still on version 3.2.0.
Need to find out which actions I need to take to do this better.

Start with a container version identical to your backup. Then move to the new version of the container.

  1. stop the OH container
  2. restore the backup
  3. start an OH container that matches the version of your restored configs versions
  4. verify the configs work
  5. stop the container and delete it
  6. start a new OH container that matches the version your want to run (upgrade or downgrade)

On that first run the container will see that the version of the configs do not match the version of the container and perform an upgrade.

1 Like

Thanks again, I was able to get a working and in-line system on my NUC, still on 3.2.0. because some of my later changes were textual (conf) but others inside Openhab which were off course lost and now I am in the process to rebuild them. Your directions were very helpful and I also (re-)found the original document you referring to.

I am too big of a novice in respect of linix/docker/openhab to have any comments on this document and appreciate the existence of what we mostly can refer as RTFM (even appreciate more that you did not slap me around the ears with it).

However, what do I miss a bit:

  • A docker-compose variant as example
  • A more simple approach to access an USB device like adding (hope I am correct):
      - /dev/ttyUSB0:/dev/ttyUSB0:rwm // not sure if the 'm'  should be included

It is possible that Backup/Restore is not really scope of this specific page, but guidelines like if you can skip or should do a stop of the container before you do a backup would be welcome advice but likely I did not turn to that page of the RTFM (so skip this observation, so many out there).

I always have to constrain myself on topics like these because I feel like the quote attributed to Jamie Zawinski about regex applies even more to Docker.

Some people, when confronted with a problem say “I know, I’ll use [Docker].” Now they have two problems.

To put it bluntly, if you don’t know Docker, you shouldn’t be using it. If you can’t not use it for some reason, you need to independently go and get smart about what it means to run something in a container, constraints, where to find the Docker reference guides, etc. The openHAB project only provides one deployment where we take on configuring, documenting, and supporting everything. If you want to run on Windows, Mac, Docker, Synology, FreeBSD, or even a basic Linux install, anything outside stuff that is core to openHAB is going to be your responsibility to understand and maintain for the most part.

Anyway, to address some of your questions and stuff you miss out on a bit, you’ll notice that the docs have a link to Dockerhub. In fact it says

Note, always review the README on Docker Hub (opens new window)for the most up to date set of recommended arguments and environment variables.

There you will find a Docker compose example, example with explanation for passing devices, etc.

As for the backup/restore, as someone running openHAB in a Docker container you already have to manage volumes for userdata and conf. All a backup does is save most of the files in userdata and all of the files in conf (and it’s OK to save all the files in userdata if you want). But there are a bunch of different ways to manage volumes in Docker and which one you are using could radically change the way you perform the backup. So this is largely left to the user to decide how they want to back up when running Docker. To a large extent it’s made outside the scope of OH because the Docker environment puts it outside the scope.

However, note that when the container is upgraded, a backup will be created automatically for you.

To be honest I fully agree with the docker remark. And yes, with at least 4 links to this page I should not have remarked that I miss a docker-compose variant. Thanks for the slap (have changed my avatar).

I’ve also opened an issue to make the docs over on Dockerhub become the docs we use in our main documentation too. That way all the good additions that are over there are also included in our docs as well.