- Platform information:
- Hardware: RPI3B+
- OS: Raspbian 9
- Java Runtime Environment: 1.8.0_171
- openHAB version: 2.3.0
- Issue of the topic: I had strange results with updating KNX items in the config files and decided to stop OH2 and clear /var/lib/openhab2/cache and tmp. After clearing the cache and starting OH2 again, I can open PaperUI and BasicUI with all bindings, sitemaps, etc. but I don’t receive any logging in /var/log/openhab2/* anymore. I connected to karaf using ssh. When executing a query regarding the logs I receive the error listed below. Please help me getting logging back to work. Thank you in advance, Rene
- Please post configurations (if applicable):
- Items configuration related to the issue
- Sitemap configuration related to the issue
- Rules code related to the issue
- Services configuration related to the issue
- If logs where generated please post these here using code fences:
openhab> log:list
21:13:36.007 [Karaf ssh console user openhab] ERROR org.apache.karaf.shell.support.ShellUtil - Exception caught while executing command
java.lang.IllegalStateException: Unrecognized configuration
at org.apache.karaf.log.core.internal.LogServiceImpl.getDelegate(LogServiceImpl.java:55) [56:org.apache.karaf.log.core:4.1.5]
at org.apache.karaf.log.core.internal.LogServiceImpl.getLevel(LogServiceImpl.java:73) [56:org.apache.karaf.log.core:4.1.5]
at org.apache.karaf.log.command.GetLogLevel.execute(GetLogLevel.java:49) [56:org.apache.karaf.log.core:4.1.5]
at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:571) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:497) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:386) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:417) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [12:org.apache.karaf.shell.core:4.1.5]
at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [12:org.apache.karaf.shell.core:4.1.5]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Error executing command: Unrecognized configuration
openhab>
After removing the log-files you have to start openHAB again.
I started OH2 after clearing cache und tmp using “service openhab2 start”. I also tried to start it in debug mode from console. Same result.
I found on another forum that people had similar problems with karaf 4.1.5 like me:
http://karaf.922171.n3.nabble.com/Karaf-4-1-5-and-log-configuration-td4052606.html
Those guys didn’t find a solution to this problem.
Now I decided to reinstall OH2.3 from scratch in case there were some leftovers from the upgrade from OH2.2. It’s working again but I still have the same strange behavior of KNX in rules. Opened a ticket on github for the KNX behavior.
I found another topic with karaf logging errors:
However, in my case (oficial docker container) userdata is in /openhab/userdata
so config file, which was magically emptied, was in /openhab/userdata/etc/org.ops4j.pax.logging.cfg, (that caused problems in karaf, when launching command that operates on logs)
Fortunately, I found file with proper content: /openhab/userdata/org.ops4j.pax.logging.cfg so copied it to emptied /openhab/userdata/etc/org.ops4j.pax.logging.cfg file and it worked…
Hope, that will save somebody from reinstalling whole openhab
Thanks Karol, found a similar discussion on the logging configuration as well. The file mentioned was not installed on my environment after the upgrade to OH2.3. I used apt-get to upgrade from 2.1 -> 2.2 -> 2.3. After the clean installation of OH2.3 there is still no “.dpkg-dist” file at the location mentioned above.
On my environment the logging configuration is located at this folder after installing the package:
/var/lib/openhab2/config/org/ops4j/pax/logging.config
I have the same problem, after i killed the java process when it hung. Once we restarted openhab.karaf, i couldn;t do log:tail or log:display … all return " Error executing command: Unrecognized configuration"
How to resolve this? All the .cfg files are intacted.
Should have read this problem… It SOLVED the problem
wow you just saved my life, thanks! wouldn’t want to redo my openhab install
This just happened to me. OH 3.2.0 (docker install).
Everything was fine. I was ssh’d to port 8101 and watching log:tail. Then, I tried running a rule in the UI that included a sendHttpPostRequest (no idea if this caused it). That’s when logging quit. and I got “Unrecognized configuration” errors referenced above
Thanks to this posting, I looked for the config file, and it was 0 size. (your location may vary by installation)
ll /volume1/docker/openhab/userdata/etc/org.ops4j.pax.logging.cfg
-rwxrwxr-x 1 openhab openhab 0 Jan 13 10:12 /volume1/docker/openhab/userdata/etc/org.ops4j.pax.logging.cfg
I couldn’t find a backup on my system, but I did find one online in github:
I replaced my 0 size file, with this one from online (It only has a single line in it)
Without even restarting, my logfiles started filling again.
BTW, after logging was working again, I re-ran the same rule from the UI (with the HttpPost) and it ran and logged just fine. No idea what caused the config file to disappear.
Thanks for posting this file’s location, solved my logging problems!
This happened to me, too. I only noticed later, but around the time logging stopped working I had installed the JSONPATH transformation service.
Adding this one line, as described above, fixed the logging issue without a restart.