OpenHAB stops watching files

[ccutrer]

This is probably on the java side.

See https://github.com/openhab/openhab-core/issues/2537. I'm not certain what's the culprit, but this seemed to start when I started using JRuby, so JRuby might be the culprit, if you happen to have any ideas.

[jimtng]

I reported it too https://github.com/openhab/openhab-core/issues/2535

Your theory about jruby causing it might have merits. I was wondering why I was the only one complaining about it, nobody commented about it on the forums either. I'll try removing jruby to see if that is the culprit.

[ccutrer]

ohmygosh I'm not alone! I've been pulling my hair out!

[jimtng]

@boc-tothefuture, it does seem that jruby is causing it. I removed jruby bundle and updated to 3.2M3 and my changes to rulesdsl and jython are being reloaded.

[jimtng]

When openhab is running without jruby and then I added the jruby jar into the openhab addons folder, jruby would load all my .rb scripts, and from that point onwards, changes to scripts (including jython and rulesdsl) are still being reloaded.

However, once I've restarted openhab, then changes to any scripts (jruby, jython, rulesdsl) are no longer reloaded. This happens on any version after 3.2M1

bundle:list -s | grep ruby
296 │ Active │  80 │ 3.2.0.202109141052    │ org.openhab.automation.jrubyscripting

[boc-tothefuture]

To clarify, we only see it in milestone builds after 3.2M1?

We don't do anything special in the jruby Java side to watch directories, etc. Are there any exceptions?

I will be at my computer and can look deeper tomorrow. Will need to to see if anything changed in jython, etc between 3.1 and 3.2.

[ccutrer]

it doesn't happen every restart of openhab for me, but nearly every. and I can't comment as to version, I've always been on >3.2M1 since using jruby. and yes, the watcher has an exception, but its logging is pitiful (see my openhab-core ticket). I'm trying to compile openhab to get better logging, but it's not exactly fast...

[ccutrer]

I can't repro with 3.2.M3 in the openhab-jruby managed instance on my dev machine (Mac).

[jimtng]

To clarify, we only see it in milestone builds after 3.2M1?

Correct. It works fine on 3.2M1. It doesn't work on 3.2M2 and after.

[ccutrer]

We'll see if this gets any traction. https://github.com/openhab/openhab-core/pull/2538

mvn install of the entire openhab-core repo finished for me, but I have no idea how to package it into something runnable, or how to inject it into my actual environment. I tried both dumping it into the addons folder, and replacing the org.openhab.core-3.2.0-SNAPSHOT.jar that the deb package installed, but it ignored the latter and marked the former as "inactive" or something. I suspect it needs to be zipped up into some larger package or something.

So hopefully my PR gets merged, then I can use a new snapshot build.

[jimtng]

but it ignored the latter and marked the former as "inactive" or something

Try clearing your openhab cache

[boc-tothefuture]

@ccutrer is it the same file enqueued every time before the exception?

[ccutrer]

Yes and no. The ordering is consistent of the enqueued files every time I restart. And it always happens after the last file. But if move the last file out, and restart again, the reader thread still crashes.

[boc-tothefuture]

@ccutrer and @jimtng what is the status here? I am not hitting this issue because I am not on a milestone. Do we think this is openhab related or something in the Jruby binding somehow?

[jimtng]

I currently suspect this is caused by the JRuby binding. When I removed jruby binding, openhab would reload rulesdsl and jython files. But when jruby binding is loaded, nothing (rulesdsl, jython and jruby) gets reloaded. This happened after 3.2M1, i.e. it works on 3.2M1 but not on 3.2M2, nor on 3.2M3.

There were some PRs from @J-N-K after 3.2M1 that might have affected it.

Looking inside the code for jython binding, they are using ScriptEngineManager whereas jruby binding isn't. I have even tried modifying jruby binding's code to be similar to Jython's but I didn't have any luck due to my lack of understanding of how it all works.

[jimtng]

I've spent some time experimenting with the binding code, although I still haven't solved the problem, I found that when I removed the activate and modified functions, although it broke openhab-jruby, script reloads worked.

I'm wondering whether multiple calls to factory.getScriptEngine() might've been the cause of the issue.

[boc-tothefuture]

Interesting.. do you have any idea what is being passed into the activate and modified code?

[jimtng]

Interesting.. do you have any idea what is being passed into the activate and modified code?

It seems that the call to configureGems is the cause.

[ccutrer]

I just had an epiphany while I was sleeping. I've done some manual gem installs from the shell into my openHAB Ruby gem_home. I bet I have bad permissions somewhere that is breaking the gem install if it needs to be updated. And I bet the boot order changed somehow in OpenHAB that it's activating the Ruby bundle inside the file watcher thread on boot (which has the terrible error handling), but somewhere else (that presumably is also just swallowing the error, but not breaking anything when it happens, unlike the file watch thread) if you're first installing or updating the jruby bundle on an already running openHAB instance. This could definitely explain why it seems to only be broken for me sometimes- if the gem is already up to date it doesn't fail.

Anyhow, I need to test this out, and we probably need better error handling here. Pretty sure I won't be able to get back to sleep, but I can't work on it now for fear of waking others up. Crazy epiphanies coming in the middle of unrelated dreams!

[J-N-K]

Please note that the AbstractWatchService is not able to handle two subscriptions to the same directory. Only the latest subscription gets notified of changes. Maybe you run into that?

[boc-tothefuture]

@ccutrer - can you look at the ruby code that does the GEM installs? Is there a better way to be doing that?

Code is here: https://github.com/boc-tothefuture/openhab2-addons/blob/bcb8e89e2486d0acc4c2b34c17ed2427e4da625a/bundles/org.openhab.automation.jrubyscripting/src/main/java/org/openhab/binding/jrubyscripting/internal/JRubyScriptEngineConfiguration.java#L93

[boc-tothefuture]

@jimtng when you tracked down that it was the GEM issue - did you still get the logging here:

logger.debug("Installing Gem: {} ", gem);
logger.trace("Gem install code:\n{}\n", gemInstallCode);

I am curious if it was breaking during the install or maybe in the parsing of the configuration on reload? I wonder if somehow the details sent to the configuration are different in M2?

[jimtng]

There were no errors in the log. Scripts just don't get reloaded.

2021-11-06 22:27:27.738 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Querying state satisfied
2021-11-06 22:27:27.739 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Querying state satisfied
2021-11-06 22:27:27.745 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : getting activate: activate
2021-11-06 22:27:27.746 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Locating method activate in class org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory
2021-11-06 22:27:27.746 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Declared Method org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory.activate([interface org.osgi.service.component.ComponentContext]) not found
2021-11-06 22:27:27.746 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Found activate method: protected void org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory.activate(org.osgi.service.component.ComponentContext,java.util.Map)
2021-11-06 22:27:27.747 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : invoking activate: activate: parameters [org.apache.felix.scr.impl.manager.ComponentContextImpl, org.apache.felix.scr.impl.helper.ReadOnlyDictionary]
2021-11-06 22:27:27.747 [TRACE] [ernal.JRubyScriptEngineConfiguration] - JRuby Script Engine Configuration: {service.pid=org.openhab.automation.jrubyscripting, rubylib=/openhab/conf/automation/lib/ruby, gem_home=/openhab/conf/automation/lib/ruby/gem_home, ruby_lib=/openhab/conf/automation/lib/ruby/personal, gems=openhab-scripting=~>4.0, component.name=org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory, component.id=276}
2021-11-06 22:27:27.748 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Ignoring unexpected configuration key: service.pid
2021-11-06 22:27:27.748 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Ignoring unexpected configuration key: ruby_lib
2021-11-06 22:27:27.748 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Ignoring unexpected configuration key: component.name
2021-11-06 22:27:27.748 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Ignoring unexpected configuration key: component.id
2021-11-06 22:27:27.749 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting system property (org.jruby.embed.localvariable.behavior) to (transient)
2021-11-06 22:27:27.749 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting system property (org.jruby.embed.localcontext.scope) to (threadsafe)
2021-11-06 22:27:27.868 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['RUBYLIB']='/openhab/conf/automation/lib/ruby'
2021-11-06 22:27:30.786 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['GEM_HOME']='/openhab/conf/automation/lib/ruby/gem_home'
2021-11-06 22:27:30.800 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Installing Gem: openhab-scripting
2021-11-06 22:27:30.801 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Gem install code:
require 'rubygems/commands/install_command'
cmd = Gem::Commands::InstallCommand.new
cmd.handle_options ['--no-document', 'openhab-scripting', '-v', '~>4.0']
cmd.execute

2021-11-06 22:27:32.193 [INFO ] [e.automation.internal.RuleEngineImpl] - Rule engine started.
2021-11-06 22:27:37.733 [DEBUG] [ernal.JRubyScriptEngineConfiguration] - Passed engine.eval(gemInstallCode)
2021-11-06 22:27:37.734 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : invoked activate: activate
2021-11-06 22:27:37.734 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Set implementation object for component
2021-11-06 22:27:37.734 [DEBUG] [ng.internal.JRubyScriptEngineFactory] - bundle org.openhab.automation.jrubyscripting:3.2.0.202111061221 (238)[org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory(276)] : Changed state from satisfied to active
2021-11-06 22:27:37.737 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['RUBYLIB']='/openhab/conf/automation/lib/ruby'
2021-11-06 22:27:38.124 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['GEM_HOME']='/openhab/conf/automation/lib/ruby/gem_home'
2021-11-06 22:27:39.318 [INFO ] [o.internal.handler.AstroThingHandler] - Scheduled Positional job astro:sun:home every 60 seconds
2021-11-06 22:27:39.346 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@37f22f6e[provider=null,keyStore=null,trustStore=null]
2021-11-06 22:27:39.387 [INFO ] [o.internal.handler.AstroThingHandler] - Scheduled Positional job astro:moon:home every 60 seconds
2021-11-06 22:27:39.390 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@37f22f6e[provider=null,keyStore=null,trustStore=null]
2021-11-06 22:27:39.580 [WARN ] [ty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@42ab2349[provider=null,keyStore=null,trustStore=null]
2021-11-06 22:27:39.580 [WARN ] [ty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@42ab2349[provider=null,keyStore=null,trustStore=null]
2021-11-06 22:27:39.851 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.19.0.1/16, truncating to /24, some addresses might be lost
2021-11-06 22:27:39.853 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.18.0.1/16, truncating to /24, some addresses might be lost
2021-11-06 22:27:39.854 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 192.168.1.10/16, truncating to /24, some addresses might be lost
2021-11-06 22:27:40.297 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'server.local' with clientid 143a9e82-907a-4bda-8f13-fdecdac988fd
2021-11-06 22:27:42.059 [WARN ] [.googletts.internal.GoogleTTSService] - Audio format OGG_OPUS is not yet supported.
2021-11-06 22:27:42.552 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 077fba73-7d9d-4458-96b9-ed57fd54e726, base URL = http://localhost:8484)
2021-11-06 22:27:47.241 [INFO ] [rt.internal.loader.ScriptFileWatcher] - Loading script '/openhab/conf/automation/jsr223/ruby/personal/aircon.rb'
2021-11-06 22:27:47.242 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['RUBYLIB']='/openhab/conf/automation/lib/ruby'
2021-11-06 22:27:47.557 [TRACE] [ernal.JRubyScriptEngineConfiguration] - Setting Ruby environment with code: ENV['GEM_HOME']='/openhab/conf/automation/lib/ruby/gem_home'
2021-11-06 22:27:50.343 [INFO ] [jsr223.jruby.OpenHAB                ] - OpenHAB JRuby Scripting Library Version 4.12.0 Loaded

Note I added a logger that prints out Passed engine.eval(gemInstallCode) just after the exception block.

[jimtng]

Please note that the AbstractWatchService is not able to handle two subscriptions to the same directory. Only the latest subscription gets notified of changes. Maybe you run into that?

@J-N-K pardon my ignorance on the openhab-core, what would've created these "subscriptions"?

Could this be a multi-threading issue?

[jimtng]

when you tracked down that it was the GEM issue

I did it by brute force - commenting things out until it started working and restoring things until it started not working.

[J-N-K]

Let's say addon creates an AddonWatchService that extends AbstractWatchService and watches /etc/openhab/automation then ONLY this instance get's notified, the watchservice in core that reloads scripts will never receive events of changed files in `/etc/openhab/automation. This is "latest wins", whoever is the last one that adds a subscription gets notified. Depending on the configuration this is also true for subdirectories. This is a bug/limitation in core. This has nothing to do with multi-threading, the issue is that only one subscription per directory is stored (instead of a list of services that wish to get notified).

[boc-tothefuture]

@jimtng - Unfortunately I have to run and will be away for several hours.. but will check back and work on this later today.

Two avenue I am looking at if you want to investigate while I am away: (1) Remove my gem install code and instead invoke the JRuby command line gem install code:

require 'jruby/commands'

ARGV = ['openhab-scripting=~>4.0']
JRuby::Commands.maybe_install_gems 

I tried that quickly and received an error message but I didn't get a chance to dive into what is going on.

2. We should probably (for performance and other reasons) only do the GEM install once on startup. This would mean you can't update your configuration and just have it grab a new GEM - instead you would have to restart. But this is probably good anyway because without that you are going to have different scripts on different versions of gems. So we would need to create a lock with a latch of some sort (boolean) and only invoke the gem install once.

[jimtng]

(1) Remove my gem install code and instead invoke the JRuby command line gem install code:

require 'jruby/commands'

ARGV = ['openhab-scripting=~>4.0']
JRuby::Commands.maybe_install_gems 

This command expects a local gem file. So when I tried, it raised an exception:

23:54:14.468 [ERROR] [ternal.JRubyScriptEngineConfiguration] - Error installing Gem
javax.script.ScriptException: Error during evaluation of Ruby in uri:classloader:/jruby/commands.rb at line 52: (RuntimeError) no local gem found for openhab-scripting=~>4.0
    at org.jruby.embed.jsr223.JRubyEngine.wrapRaiseException(JRubyEngine.java:275) ~[bundleFile:?]
    at org.jruby.embed.jsr223.JRubyEngine.doEval(JRubyEngine.java:100) ~[bundleFile:?]
    at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:116) ~[bundleFile:?]
    at org.jruby.embed.jsr223.JRubyEngine.eval(JRubyEngine.java:145) ~[bundleFile:?]
    at org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineConfiguration.configureGems(JRubyScriptEngineConfiguration.java:127) [bundleFile:?]
    at org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineConfiguration.configureScriptEngine(JRubyScriptEngineConfiguration.java:88) [bundleFile:?]
    at org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineConfiguration.update(JRubyScriptEngineConfiguration.java:70) [bundleFile:?]
    at org.openhab.binding.jrubyscripting.internal.JRubyScriptEngineFactory.activate(JRubyScriptEngineFactory.java:81) [bundleFile:?]
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
...

However, since that exception was caught, things proceed as normal and it didn't break the file watcher, i.e. changes are reloaded.

So we can possibly use this, coupled with a way to download the gem(s)?

2. We should probably (for performance and other reasons) only do the GEM install once on startup. This would mean you can't update your configuration and just have it grab a new GEM - instead you would have to restart. But this is probably good anyway because without that you are going to have different scripts on different versions of gems. So we would need to create a lock with a latch of some sort (boolean) and only invoke the gem install once.

As far as I can tell, the current code with activate only gets called once, and therefore the Gem installation is only done once, unless the binding is restarted. So from this perspective, no change is needed. I did play around with setting a flag and installing the gem not in activate but in createScriptEngine but it didn't make a difference to the problem.

[boc-tothefuture]

If it doesn't get called more than once how is the gem code impacting file watches?

Very odd.

[ccutrer]

Because the file watcher thread that openHAB uses for all watching dies.

[jimtng]

SUCCESS!

You gave me an idea. I tried using the inline bundler and that seems to be working!! I will submit a PR and @ccutrer can also be a tester.

[jimtng]

I see errors when replacing the binding's jar while openhab is running. If openhab is restarted after updating the binding's jar, then everything works, including script reloads.

[ccutrer]

\o/ it worked! I did have a bit of trouble upgrading things; it did take a couple reboots. but file watching still works. I am getting an incredibly long stack trace in my log though:

https://gist.github.com/ccutrer/f8e70fb045717ed91978307b3bd56cd9

this is with a locally compiled bundle, as of https://github.com/boc-tothefuture/openhab2-addons/commit/bfea1f860f156d8f427805504371a2d1ed4fa90e

[jimtng]

I am getting an incredibly long stack trace in my log though:

https://gist.github.com/ccutrer/f8e70fb045717ed91978307b3bd56cd9

I got the same error / exception when the bundle got replaced while openhab is running. It doesn't occur when restarting openhab.

[github-actions[bot]]

:tada: This issue has been resolved in version 4.13.0 :tada:

The release is available on:

• 4.13.0
• GitHub release

Your semantic-release bot :package::rocket:

[jimtng]

Thanks to @ccutrer's suggested change in https://github.com/openhab/openhab-core/pull/2538, I managed to pinpoint the bug in openhab-core and submitted a PR https://github.com/openhab/openhab-core/pull/2563

If it gets merged, would we consider moving the GEM_HOME back into conf/automation/lib, even though it would generate these warnings below (caused by the gem installer). If we decide to keep it out, feel free to re-close this issue.

2021-11-08 15:55:40.821 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@521d9268' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@2789d0b1' for entry 'number.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.822 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@6305a2f4' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@2789d0b1' for entry 'ruby.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.823 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@32326d27' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@2789d0b1' for entry 'string.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.863 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@a99e4b0' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@5d34fa42' for entry 'month_day.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.864 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@367cb3b4' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@5d34fa42' for entry 'time_of_day.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.865 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@18cdc94b' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@3451b50d' for entry 'manager.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.866 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@69224f1e' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@3451b50d' for entry 'reentrant_timer.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.867 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@624bf11c' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@3451b50d' for entry 'timer.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.893 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@2692a6cb' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@1e940680' for entry 'configuration.rb' in not registered file or directory of 'null'
2021-11-08 15:55:40.895 [WARN ] [penhab.core.service.WatchQueueReader] - Detected invalid WatchEvent 'sun.nio.fs.AbstractWatchKey$Event@58bf1180' and key 'sun.nio.fs.LinuxWatchService$LinuxWatchKey@1e940680' for entry 'logger.rb' in not registered file or directory of 'null'

[jimtng]

The PR to fix this in openhab-core has been merged.