Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial devices appear to use the same lock file #671

Closed
kolaf opened this issue Feb 20, 2016 · 27 comments

Comments

Projects
None yet
9 participants
@kolaf
Copy link

commented Feb 20, 2016

I'm running three bindings that connect through emulated USB serial ports (I believe in different fashions): zwave (the latest unofficial release for OH2), mysensors, and rfxcom. I'm running as root (only way I have found to get full access to the serial ports) under ubuntu 14.something.

Initialising the first device (mysensors) went smoothly after installing the prerequisite serial bundle: feature:install openhab-transport-serial. Next, initialising the zwave bundle failed with a message something like this (this is not entirely correct I lost the log from that issue):

RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

@L" testRead() Lock file failed

The message was slightly different, but it referenced the lock file for the mysensorsUSB device, not for zwave. Rebooting OH2 made things work.

Finally, failing to automatically discover the rfxcom device because of the Linux FTDI driver issue, I set up the bridge manually. This resulted in the following error message:

 Loading model 'rfxcom.things'
13:13:33.178 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'rfxcom:bridge:rfxtrx' has been added.
13:13:33.195 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed     from UNINITIALIZED to INITIALIZING
13:13:33.198 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'rfxcom:bridge:rfxtrx' changed from INITIALIZING to OFFLINE
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

@L" testRead() Lock file failed
13:13:33.204 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null
13:13:33.207 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'rfxcom.things'

Restarting OH2 does not seem to resolve this, so I am unable to use both mysensors and rfxcom at the same time. Unloading the FTDI driver is not an option, because this makes the mysernsors device unavailable.

@cdjackson

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2016

If I remember correctly, the lock file is handled by the serial driver (well, everything to do with the actual serial port is handled by the driver).

https://github.com/NeuronRobotics/nrjavaserial

There is also an open issue associated with lock files that came out of the zwave binding - you might be interested in taking a look and adding to their discussion? NeuronRobotics/nrjavaserial#60

@kolaf

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

It looks like that issue was closed, without me getting any wiser on how or why. Not sure I can contribute any more than reporting what I saw :/

@cdjackson

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2016

The issue I referenced is still open NeuronRobotics/nrjavaserial#60 NeuronRobotics/nrjavaserial#60

@kolaf

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

Sorry, I misread the labels on the final post. I get the same issue when reconnecting the zwave dongle. I can give them the same log as I posted here and see what they say.

@mnlipp

This comment has been minimized.

Copy link

commented Feb 20, 2016

Your lock file has a rather strange name. Usually, lock files have names such as LCK..<dev> with <dev> being something like ttyUSB0 or ttyACM3. You mentioned that you use "emulated USB serial ports". Could you elaborate a bit on that? From the look of your lock file, you should have a "/dev/mysensorsUSB". How can you get such a thing?

@kolaf

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

/dev/mysensorsUSB is a symlink to /dev/ttyUSB1 which is created automatically whenever the device is plugged in as per a recipe in the openhab wiki somewhere. It is to ensure that it has the same name after every boot and plug in/plug out.

By emulated USB serial ports I simply mean generic FTDI devices, devices you plug into the USB port but act as serial ports, as they typically do. Nothing special there, just me not phrasing myself correctly :-)

@mnlipp

This comment has been minimized.

Copy link

commented Feb 20, 2016

Okay, so /dev/mysensorsUSB -> /dev/ttyUSB1 works. The problem occurs when you try to connect your second USB device (zwave). From the error message (/var/lock/LCK..mysensorsUSB: File exists.) it appears that you configured the zwave component to use the same USB device, hence the message.

I'd suggest to try three configurations each using only one of the USB devices one after the other. When they run, have a look at what files are created in /var/lock. Should be different files in all cases.

@kolaf

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

They are not using the same USB device, zwave is connected through /dev/ttyACM0. But sure, I'll disable all three bindings and go through them one by one.

@kolaf

This comment has been minimized.

Copy link
Author

commented Feb 20, 2016

I've tested initialising the services in different orders and this is what I have found:

It appears that everything is related to the RFXCOM binding. It never works regardless of which order I configure things, and the two other bindings always work. One point that might be interesting finding the issue with the rfxcom binding is that when I initialising as the first binding I get the simple error message:

15:59:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Checking RFXCOM transceiver connection, thing status = OFFLINE
15:59:14.741 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Connecting to RFXCOM transceiver
15:59:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Disconnecting
15:59:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Closed
15:59:14.777 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null

However, as soon as I install the mysensor binding the error changes to this:

16:00:11.205 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mysensors.things'
16:00:11.232 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'mysensors:bridge-ser:gateway' has been added.
16:00:11.256 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from UNINITIALIZED to INITIALIZING
16:00:11.294 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-ser:gateway' changed from INITIALIZING to ONLINE
16:00:11.295 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'mysensors.things'
16:00:13.637 [WARN ] [essage.ApplicationUpdateMessageClass] - Got ApplicationUpdateMessage without request, ignoring. Last message was SendData.
16:00:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Checking RFXCOM transceiver connection, thing status = OFFLINE
16:00:14.740 [DEBUG] [g.rfxcom.handler.RFXComBridgeHandler] - Connecting to RFXCOM transceiver
16:00:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Disconnecting
16:00:14.741 [DEBUG] [rnal.connector.RFXComSerialConnector] - Closed
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..mysensorsUSB: File exists. It is mine

eP$ testRead() Lock file failed
16:00:14.742 [ERROR] [g.rfxcom.handler.RFXComBridgeHandler] - Connection to RFXCOM transceiver failed: null

This is regardless of what I do with the zwave controller. I will point the rfxcom guys to this issue for details.

@mnlipp

This comment has been minimized.

Copy link

commented Feb 20, 2016

I think something goes wrong here (obviously), but it is not related to the serial driver's locking. The root course is that your RFXCOM connection isn't working. I think you should get that working first in a configuration without the other components.

Looking at the source code (e.g. https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.rfxcom/src/main/java/org/openhab/binding/rfxcom/handler/RFXComBridgeHandler.java) I see quite proper usage of debug logging. Try to run your configuration with log level debug. That should provide more hints.

@dennisausbremen

This comment has been minimized.

Copy link

commented Mar 3, 2016

Did anyone actually had success building a working org.openhab.io.transport.serial for the OH2 Beta2 with the prerelease from https://github.com/NeuronRobotics/nrjavaserial/releases/tag/3.12.0?

@mnlipp

This comment has been minimized.

Copy link

commented Mar 4, 2016

Pre-release doesn't work, looking into it...

@mnlipp

This comment has been minimized.

Copy link

commented Mar 4, 2016

It doesn't work because most native libraries haven't been recompiled, and those that have been recompiled aren't used ;-) (see NeuronRobotics/nrjavaserial#60).

@dennisausbremen

This comment has been minimized.

Copy link

commented Mar 6, 2016

As you stated in NeuronRobotics/nrjavaserial#60, do you have a version of org.openhab.io.transport.serial.jar for us we can test?

@mnlipp

This comment has been minimized.

Copy link

commented Mar 6, 2016

What version should I give it in order to not produce something that "gets around" and causes confusion?

@dennisausbremen

This comment has been minimized.

Copy link

commented Mar 6, 2016

Some "-pre" or "-test"?

@mnlipp

This comment has been minimized.

Copy link

commented Mar 6, 2016

Are you sure that this complies with OSGi rules?

@dennisausbremen

This comment has been minimized.

Copy link

commented Mar 6, 2016

No I'm not. But I saw some forks of OH with tagged prereleases for testing, or simply direct links.

@mnlipp

This comment has been minimized.

Copy link

commented Mar 6, 2016

I'm going to try to package something. I had uses a hacked 1.7.1 for my tests (simply replaced the nrserial jar), but I don't want to publish that.

@mnlipp

This comment has been minimized.

Copy link

commented Mar 6, 2016

How do I properly replace a jar with a newer version for testing? I have removed org.openhab.io.transport.serial-1.7.1.jar from server/plugins and put my org.openhab.io.transport.serial-1.8.0-test.jar there. But it doesn't seem to be used (no "auto-deploy"). Do I have to change some configuration file?

(Probably a silly question, if you know about OSGi, but I was trying to learn how OSGi works by taking OpenHAB as an example when I found that I couldn't get my RXComm working which led me to nrjavaserial which led me to the lockdir problem which led me to how to cross-compile the native libraries... So I still don't know a lot about OSGi.)

@watou

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2016

I have removed org.openhab.io.transport.serial-1.7.1.jar from server/plugins and put my org.openhab.io.transport.serial-1.8.0-test.jar there.

It's not intuitive, but remove the old one from server/plugins, but put the new one in addons. This is more of an openHAB thing than a generic OSGi thing. 😄

@mnlipp

This comment has been minimized.

Copy link

commented Mar 7, 2016

There seem to be some restrictions on the version number patterns, so my initial attempt with 1.8.0-test failed. Since openhab doesn't actually add any value to the library expect for packaging it as an OSGi component, I decided to use the nrjavaserial number for versioning, so 3.12.0.a1 in this case.

Deployment as described by @watou didn't work either. Since I tried several things, I cannot be perfectly sure, but I think you have to replace the jar in server/plugins and issue an update file:/... command in the console. (I strongly suspect that the location of the jar doesn't matter at all, and that server/plugins is only used for the initial population of the server. Hopefully I'll have some time now to have a closer look at that OSGi stuff.)

You can download the bundle from https://github.com/mnlipp/nrjavaserial/releases. It successfully connects my RFXComm with openhab on my Raspberry Pi 2 running Arch Linux, using locking as it should. You can find an enumeration of the environments where it should work in the release notes. Make sure to install the package that provides liblockdev on your system.

@paulianttila

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2016

Should we update nrjavaserial to version 3.12.0. It still seems to be pre-release, but nothing has happen since 20th of feb.

@kaikreuzer

This comment has been minimized.

Copy link
Member

commented Nov 11, 2016

NeuronRobotics/nrjavaserial#44 is still a blocker for me. If the project is dead, we can discuss to fork it and take over - but we would need someone willing helping to maintain it.

@kaikreuzer

This comment has been minimized.

Copy link
Member

commented Aug 16, 2018

FTR, we meanwhile use version 3.14.0, but NeuronRobotics/nrjavaserial#60 is still open, so the locking issue continues to exist.

@wborn

This comment has been minimized.

Copy link
Member

commented Dec 20, 2018

The current status (20-12-2018) is that:

  • The official nrjavaserial releases are still build with liblockdev causing issues on some distributions (NeuronRobotics/nrjavaserial#60)
  • After having used the official nrjavaserial 3.14.0 release we ran into these locking issues again (see community thread)
  • We now cross compile an openHAB nrjavaserial JAR using the official sources while disabling liblockdev (nrjavaserial-builder)

@davidgraeff davidgraeff added the bug label Mar 18, 2019

@davidgraeff

This comment has been minimized.

Copy link
Member

commented Mar 18, 2019

We now cross compile an openHAB nrjavaserial JAR using the official sources while disabling liblockdev

I'm closing this then :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.