Communication to /dev/usb/lp0 port no longer works via Java application using RXTX library

Hello everyone,

Our IT company has been using OpenSUSE Tumbleweed for the past 2 years without issues. However last week we discovered a potetional bug. Our communication with a USB printer via lp0 port no longer works and our Java application reports

device.DeviceException: gnu.io.NoSuchPortException

Working version - 20220531-0
Updated version - 20240228-0

When I update our working version, the lp0 port stops working. However I can still send some test prints via echo.

Anybody experienced similar behaviour?

Also one important thing which I forgot to mention. When our app is launched under root it works. So permission somehow got screwed?

Check the group ownership (eg lp group)

ls -l /dev/usb/lp0

and add the user to that group if necessary.

crw-rw---- 1 root lp 180, 0 May 6 09:55 /dev/usb/lp0

uzivatel : users lock tty dialout lp

This worked pre-update, does not work after updating OS.

Are you saying that the device node ownership is different after the OS update? Or that it fails in some other way?

No the device node should be the same. Echo works pre-update and after update. But our Java app no longer sees the port hence device.DeviceException: gnu.io.NoSuchPortException.

Oh, so not a hardware or device node issue as such, but related to the application library. Probably best moved to Programming/Scripting category IMHO.

Thank you.

Just in case the following is helpful to you (maybe you can set the desired character port explicitly?)
http://rxtx.qbang.org/wiki/index.php/Trouble_shooting#How_does_rxtx_detect_ports.3F__Can_I_override_it.3F

"How does rxtx detect ports? Can I override it?

rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as ‘ttyS’, ‘ttym’, and since 2.2 ‘ttyUSB’ and so on.

Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports.

If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example

java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp

will look kind of like Solaris, if you have created the appropriate device nodes.

A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux.

You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need."

This unfortunately does not work. However we have found out that even ttyS* ports no longer work in our app when launched under normal user. When running our app as root, the device connected to ttyS0 operates normally.

Repeating it over and over again is not going to help. You are the only one who can troubleshoot it. Enable verbose/debug output in your application or may be use strace to find out what fails exactly. It is possible that some operation your program does now requires additional capabilities, but we have no way to guess it.

Debugging some more has revealed this error:

check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock file.

/var/lock is owned by root:root drwxr-xr-x

Pre-update installations are ownder by root:lock drwxrwxr-x

Why the sudden change of ownership of that directory? Currently figuring out how to change it permanently.

This is user to user forum. It may be intentional and it may be unintentional. You need to ask developers. Open bug report, provide your use case.

Copy /usr/lib/tmpfiles.d/fs-run.conf to /etc/tmpfiles.d and edit as needed.

Thanks, will do.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.