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

usb
device
Tags: #<Tag:0x00007f15e8199880> #<Tag:0x00007f15e81996f0>

(Bastiaan van Haastrecht) #1

Hello,

I’m running openHAB 2.4.0 Build #1322 within a docker container for two weeks and suddenly my Zwave and Zigbee USB dongles no longer work. Karaf shows these messages:

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

0 k testRead() Lock file failed
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK…ttyACM0: File exists. It is mine

0 k testRead() Lock file failed

Have restarted openHab, restarted my Synology NAS with no luck.

USB devices are present, docker runs in highes access level mode. The permissions on /dev/ttyUSB0 and /dev/ttyACM0 are ok.

So I really don’t understand why this is happening? Any ideas?

Regards,
Bastiaan


(Scott Rushworth) #2

I have seen this occasionally using snapshot 1325, but I never got to the bottom of it. I think it was an OH restart that resolved it for me. Did you try restarting the container, or is it setup to restart when the NAS reboots? Not much info for you, but you’re not alone!


(Bastiaan van Haastrecht) #3

Good to hear I’m not alone on this. Have rebooted the NAS multiple times, and so the docker container. It doens’t solve it.

I have created a github issue to ask the developers to take a look at it: https://github.com/openhab/openhab-core/issues/383


(Scott Rushworth) #4

I had been running OH as root when seeing this, but I recently changed to using an opehab account and found an issue that could be related. I mentioned this here. Check the permissions of /run/lock to see if the account running OH can’t write the lock file. If not, here is what I did…

Add openhab user to the lock group:

#usermod -a -G lock openhab

Verify membership:

#id openhab
uid=964(openhab) gid=963(openhab) groups=963(openhab),5(tty),18(dialout),54(lock)

Temporarily change group owner of /run/lock and add group write permission to see if this fix will work for you

#chown root:lock /run/lock
#chmod g+w lock

The /run/lock is recreated after each restart, so you need to make this change to set the group owner of /run/lock and add the group write permission:

#vi /usr/lib/tmpfiles.d/legacy.conf

Look for this line:

d /run/lock 0755 root root -

Comment it out (add a hash symbol before it) and insert a new line with:

d /run/lock 0775 root lock -

Save. Restart openHAB and verify functionality. Upon reboot, the permissions on /run/lock should be set with ownership root:lock and permission mask 775. I’m still investigating this, but I think it may be a new issue. I’m currently on 1330 and have not seen this issue again.


(Bastiaan van Haastrecht) #5

I’m running openhab from docker on a Synology NAS. The openhab container runs with high privilege, so I take it runs with root. So do you think the same steps would apply to my environment?


(Bastiaan van Haastrecht) #6

Permissions on /run/lock:

root@NAS02:~# ls -la /run/ | grep lock
drwxr-xr-x  6 root     root            220 Aug 14 21:30 lock


(Scott Rushworth) #7

I may be taking you down a rabbit hole. The actual error you are seeing means that the lock file was not cleaned up (OH not shutdown properly, power outage, etc.). Docker adds another layer to this. Try shutting down OH (not the container) properly with CTRL-D in Karaf. The lock files should be cleaned up. I think I had to install ssh for this when I was playing with the Docker image. I know you said you have restarted OH, but maybe you were just restarting the container or killing the Java pid? Another option is to manually delete the lock files before starting OH, after an improper shutdown.


(Bastiaan van Haastrecht) #8

Previously, I shutdown OH containter via Docker. Now I did some cleanshutdowns via karaf. The ‘LCK…ttyACM0’ lock file gets removed, but ‘LCK…ttyUSB0’ isnt. I list the files thru karaf with ‘shell:ls’:

openhab> shell:cd '/run/lock'
openhab> shell:ls
LCK..ttyACM0 LCK..ttyUSB0
openhab> shell:ls

I first want to try to delete ‘LCK…ttyUSB0’ as it looks like that one doenst get deleted. Karaf and shell doenst seem to have a way to delete files. Do you know other way to do this? Enable SSH in the container?


(Scott Rushworth) #9

That’s how I would do it… don’t know of any other way.


(Bastiaan van Haastrecht) #10

And do you recal how you did this?


(Bastiaan van Haastrecht) #11

I actually found the files within the docker folder structure:

/volume2/@docker/btrfs/subvolumes/8054d215f06ee16eb42d66929168bfe403b484366ef7db36b7d3d9d76947e5b5/run/lock

Checked with Karaf, and the file dates match. When I shutdown OH, the lock files do get deleted. So I think the origen of the problem is not that the files already exist.


(Scott Rushworth) #12

If you shutdown OH, delete the files, and restart OH, do you still get the error?


(Bastiaan van Haastrecht) #13

Yes, the errors come again:

RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine                                  
                                                                                                                           
$r testRead() Lock file failed                                                                                           
RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyACM0: File exists. It is mine                                  
                                                                                                                           
$r testRead() Lock file failed 

I’ve done a chmod 777 to the files while OH is running, error remains.


(Scott Rushworth) #14

This looks like it may be an ESH issue with nrjavaserial, but possibly with Docker factors in play. Snapshot build 1330 has ESH 0.10.0.201808130936 and nrjavaserial 3.14.0, which was merged into ESH on July 5th. The previous version was 3.12.0. Which version of nrjavaserial do you have (in Karaf, list |grep serial)? Maybe you could try an earlier snapshot, or 2.3 to see if the error occurs there too?