This is a problem which is being kicked around on another mailing list, devoted to the wview weather server, without very good results, so I have taken the liberty of putting it to a wider audience:
I have a system with a device (a Davis VantagePro2 weather console) attached to a USB port. When the system starts, the device is visible as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine till suddenly the device disappears from /dev/ttyUSB0 and appears as /dev/ttyUSB1, at which time the server fails.
I suspect (though without much evidence) that the reason for the device moving around is that there is a brief interruption of service from the device, so that it appears to the computer that a *new* device has appeared, which it has to find a device name for before it had deleted the old name of the device.
I have tried the obvious, to open what ought to be the permanent location of the device, namely: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 But the software stops working when the change takes place, evidently because /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 is a dynamically updated symbolic link to /dev/ttyUSB0 or /dev/ttyUSB1, as the case may be. The server can only be made to work again by restarting it.
Does anyone know of a way to keep the USB device open at a known location, maybe by creating a permanent entry in /dev, and bypassing udev? Any more theories about what, in general, is happening?
Thanks - jon
as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine till suddenly the device disappears from /dev/ttyUSB0 and appears as /dev/ttyUSB1, at which time the server fails.
You need to fix the server.
I suspect (though without much evidence) that the reason for the device moving around is that there is a brief interruption of service from the device, so that it appears to the computer that a *new* device has appeared, which it has to find a device name for before it had deleted the old name of the device.
That sounds likely - dmesg will probably tell you.
Does anyone know of a way to keep the USB device open at a known location, maybe by creating a permanent entry in /dev, and bypassing udev? Any more theories about what, in general, is happening?
Even if you overwrote the old device node the server needs to re-open the file handle. Given the server will get notification that the port has failed (eg a SIGHUP or going ready for read and getting an error on the read) it shouldn't be too hard to fix it.
Alan
Jonathan Ryshpan writes:
I have tried the obvious, to open what ought to be the permanent location of the device, namely: /dev/serial/by-id/usb- Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 But the software stops working when the change takes place, evidently because /dev/serial/by-id/usb- Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 is a dynamically updated symbolic link to /dev/ttyUSB0 or /dev/ttyUSB1, as the case may be. The server can only be made to work again by restarting it.
That strongly suggests that, even if the device reconnects under the same name, your software app will still choke. If your app still chokes if it's told to open /dev/serial/by-id, then it's going to have a problem when your USB device disconnects and reconnects, even if it keeps the same /dev/ttyUSB? name. You've just proven this yourself: by pointing your software to open /dev/serial/by-id. After all, the device name now, as far as your software is concerned, remains the same. The fact that the underlying symlink changes is irrelevant; unless your software manually checks if it is opening a symlink, then reads it and proceeds to use the real path. This seems very unlikely.
So, your real problem is that your software is unable to handle the device disconnecting and reconnecting. The different device name is a red herring. Either the software needs to get fixed, so at least it can recover by reopening the device (and you pointing it to the unchanged /dev/serial/by-id path), or the underlying root cause of your USB device disconnect must be identified, and fixed.
On Tue, 05 Jun 2012 19:22:50 -0400 Sam Varshavchik wrote:
Either the software needs to get fixed, so at least it can recover by reopening the device
Libudev might help with this, and what the heck, it would probably be nice if the software could handle a user yanking out the device as well (which would look much the same).
Once upon a time, Jonathan Ryshpan jonrysh@pacbell.net said:
I have a system with a device (a Davis VantagePro2 weather console) attached to a USB port. When the system starts, the device is visible as /dev/ttyUSB0. A wview server attaches to /dev/ttyUSB0 and runs fine till suddenly the device disappears from /dev/ttyUSB0 and appears as /dev/ttyUSB1, at which time the server fails.
I've had this happen on occasion (not often) with a GPS receiver used for NTP. The reason the reconnected USB device gets a different node/name is that your service is still connected to the old device node, so it can't be reused.
Your service should notice that the serial device went away and exit. I'm not sure if there's a way to have udev run a script or send a signal when a device goes away.
-
Alan Cox -
Chris Adams -
Jonathan Ryshpan -
Sam Varshavchik -
Tom Horsley