There were nearly no changes to the ZWave binding for a long time before M4 - apart from database changes and one or two critical issues which did not relate to Serial/USB.
Prior to M4, all changes went into the development branch of the binding which has now been merged into master.
I’d like to help and get to the root of this issue, but I’ve no idea what to do, to build it (and all dependencies) myself without eclipse
I have experienced similar problems on 2.4.0-SNAPSHOT (Qnap container station with Docker image). I have managed to find the files LCK.tty.ACM0, deteleted them and restarted the Docker image. It is working so far, OpenHAB communicates with the USB (Aeon) stick. I will try to shut down OpenHAB the right way.
@Kai it looks like the openHAB nrjavaserial fork had a commit which disabled lock files.
See also this comment by @cvanorman before the fork was used.
It doesn’t look like the official nrjavaserial code contains these changes.
We started using the offical nrjavaserial release again around July 15th.
There is another community thread about these lock file issues before these lock files were disabled in the OH fork.
I did some testing by:
/openhab/runtime/system/com/neuronrobotics/nrjavaserial/3.14.0/nrjavaserial-3.14.0.jar
userdata/cache and userdata/tmp
That resolves the issue for me. I also checked /var/run/lock and the libraries of the OH fork don’t generate any lock files there. So that confirms the issue is caused by the missing commit.
Should we revert back to our own fork @Kai? Looks like these lock file issues were also one of the reasons for using the fork (see your comment in 2016).
Yes, looks like it. I actually asked @cvanorman if his changes were included in the official release before switching back, but it seem he never did a PR against the official repo with that.
Should we revert back to our own fork @Kai?
Well, we cannot revert back to the 3.12.0.OH release that we did as this is lacking rfc2217, which we by now require. So we would have to build a new version and I personally have never tried to figure out how building all the native libraries actually works and how I could test it. If anyone else would be interested in maintaining such a fork, this might be a good moment to speak up 
.
In any case, I was considering to open a discussion about the serial lib as nrjavaserial as a project seems to be dead - see e.g. here or here - there is simply no reaction from the project owners anymore.
I am not too fond of creating yet another fork / serial library for Java - imho, there are plenty of them out there, almost all of them are half-heartedly maintained and none is really “the one to go for”. What would you think about opening a bigger discussion within the Java community to see, whether there is interest in joining forces on a single implementation that is maintained by a couple of people and where contributors could be sure that patches are processed?
As a short-term solution we could perhaps undo the rfc2217 removal commit on our own fork and build a JAR with the native libraries we previously used?
Yes that will most likely result in the most sustainable solution in the long run.
I haven’t programmed myself with C for years though. 
We would lose all thechanges that were done in 2017 - and if we try to include them as well, I am not 100% confident if the native binaries really still fully fit the Java code, so building it from the sources would imho be the cleaner solution.
Yes recompiling them would be the cleanest solution. This PR suggests that many of the libraries can be cross compiled.
For Docker we could also create a simple workaround by cleaning the locks in /var/run/lock whenever the container is started (before starting openHAB).
Would you want to give it a try? If not, I would also be ok to dare doing the approach you tested above and see whether any bug reports come up…
I created a nrjavaserial-builder Docker container that uses the Makefile.ubuntu64 with Ubuntu 18.04 for building the native libraries without the lock files.
So far the Linux 64 library seems to work. 
I haven’t tested the other libraries but I could also give it a try on my RPi3. The resulting artifacts have been added as the nrjavaserial-3.14.0-nolockfiles release.
Travis also immediately liked this Docker container with the first build.
Sounds awesome!
Shall I upload this to our bintray repo and make the distro build take it from there?
You mention that it hasn’t been recompiled for ARMv8 - but wouldn’t this be required for the RPi?
(sorry for my late response, I am in bed with a flu since yesterday morning and hardly able to look at a screen 
)
I’ve added some more patches to the Makefile to:
So far it seems to work on Linux x86_64 and my RPi3 (which typically runs in ARMv7 mode).
We could use the second release to see if it works for more people.
Hope you get well soon! 
Ok, so I have
These changes should make the patched library become bundled with the distro.
The patched library is still not being used. Probably some features need to be updated to use the new group ID? The old fork just had a different version number. A different group ID is cleaner but also more work.
It would be nice if your binary could use a unique version like 3.14.0.OH (like we previously had 3.12.0.OH) - this way, we would have a chance to tell OSGi that we want that version - currently, we can only say that we want 3.14.0, but this can also be resolved against the official release.
@Kai There’s now a 3.14.0.OH release using that unique version.
Thanks! I have uploaded it to Bintray and replaced it in the target platform.
And I have created https://github.com/openhab/openhab-core/pull/430, which should hopefully pin this version to be used by Karaf for the serial feature.
The updated library is now part of 2.4.0-SNAPSHOT build # 1420.
Let’s hope it doesn’t cause any new regressions or compatibility issues. 
@wborn Surprisingly, there’s new activity on nrjavaserial tonight - the maintainer just merged a few PRs and prepares a 3.15.0 release as it seems: https://github.com/NeuronRobotics/nrjavaserial/commits/master
I assume our lock issue is nonetheless still open, because no PR has ever been created about it :-/. I would like to see https://github.com/NeuronRobotics/nrjavaserial/pull/121 in openHAB, though as we could remove JNA again from the distro. Do you think you can compile a new 3.15.0.OH version? The native binaries should actually not have changed, so there’s a good chance it should work, wdyt?