-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Resource temporarily unavailable Cannot lock port #2735
Comments
Were you able to fix this issue? |
The problem seems to come from a nodejs dependency. Versions higher than 20.2 have the defect. I got around the difficulty by downgrading all my installations to v20.2.0 |
I am running raspbian on a pi 3 Getting the same issue on node 18 |
Having the same problem with version 12.0.0 NodeJS 20.8.0. Simple repro script: import { SerialPort } from 'serialport'
let port: SerialPort
function open() {
const path = '/dev/ttyUSB0'
if (!port) {
port = new SerialPort({
path,
baudRate: 9600,
dataBits: 8,
parity: 'none',
stopBits: 1,
autoOpen: false
})
port.on('error', err => {
console.log('Error: ', err.message)
})
port.on('close', () => {
console.log('Port closed')
})
port.on('open', () => {
console.log('Port opened')
})
// THIS CAUSES THE ERROR
port.on('data', data => {
console.log('Data: ', data)
})
}
port.open(err => {
if (err) {
return console.log('Error opening port: ', err.message)
}
setTimeout(() => {
close()
}, 3000)
})
}
function close() {
port.close(err => {
if (err) {
return console.log('Error closing port: ', err.message)
}
setTimeout(() => {
open()
}, 3000)
})
}
open() I discovered that by removing the |
Seems NodeJS 18.19.0 (latest now) WORKS but 20.11.0 (latest now) still doesn't. |
I encounter the same problem in my program and made some discoveries by executing the code of @robertsLando with debug flags.
In the first output logs, it seems like :
I tested with a device continuously sending data, and the problem haven't ocurred. Hope this can help to solve the issue ! |
I had the same problem on Node v20.10.0. I debugged 8+ hours with this simple Code:
The solution for me was to upgrade Node to Version v21+ (v21.6.2). On 21+ it works like a dream and without clear the "data" listener! |
Thank you @DasSamsi for your return ! |
This seems to have been recently fixed in node 20.11.1 and 21.6.2 (i just tested a bunch of versions using @DasSamsi's reproducer), as everything prior to 21.6.2 is broken too. |
The root cause seems to be related to libuv using io_uring in 20.11.0 and 21.6.1, which has been disabled in the newer node / libuv versions (node-v21.6.2/deps/uv update from 1.47.0 to 1.48.0):
vs.
UPDATE: First broken version is Node 20.3.0, which updates libuv to 1.45.0: UPDATE #2: Libuv 1.48.0 update is unrelated, NodeJS commit that disabled io_uring by default (to fix the CVE-2024-22017 setuid() issue): nodejs/node@686da19abb |
@stknob Thanks for the reference, so this should work for every (latest) nodejs version as of today |
I can still reproduce this bug in Arch Linux using NodeJs v21.6.2, serialport 12.0.0, and libuv 1.48.0, |
@fcapano Does Arch set the UV_USE_IO_URING=1 environment variable somewhere? |
@stknob no, doesn't look like it's set. |
Hello, I'm running Node v22.1.0, and still getting this error in my Electron app, when running in dev mode. Every time I make a change in my app and recompile - I'm getting this error:
Only way to fix it is to quit the app and relaunch in dev mode. Any ideas how to fix this? |
Hey @fcapano - could you please clarify? How do I go about exporting this environment variable? Thanks! |
try set lock to false |
SerialPort Version
12.0.0
Node Version
v20.8.0
Electron Version
No response
Platform
Linux calimero 6.6.3-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 29 Nov 2023 00:40:39 +0000 x86_64 GNU/Linux
Architecture
x64
Hardware or chipset of serialport
FTDI
What steps will reproduce the bug?
What happens?
on the second opening an error occurs, showing that the first connection, despite having been closed, still locks the port
If I remove
p.on('data' ... )
from the test, the error does not appear, which shows that whatever port is used it is held by the process indefinitely. Same problem if I replacep.on('data', ... )
byp.read( ...)
.did I miss something? Someone would have any idea ?
What should have happened?
The port, once closed, should have reopened without error.
Additional information
No response
The text was updated successfully, but these errors were encountered: