Repository navigation
SerialPort turns stale if device is unplugged on linux #121627
Description
Describe the bug
When a serial device is replugged on linux the device node is recreated (doubly so for dynamic device nodes/links created by udev rules). When pointing the SerialPort at such a link and replugging the device the SerialPort class does not notice that its using a stale handle, future communication fails though writes/reads simply return no info. The port still reports that its open
To Reproduce
- Use Linux
- Attach a serial device
- Create a serialport for the device
- Verify that you can write and read from the device and that the serialport reports that its open
- Unplug the device
- Verify that Serialport still reports that its open but that reads and writes now go into the void but no exceptions are logged
Exceptions (if any)
None
Further technical details
details of dotnet --info
.NET SDK: Version: 10.0.100 Commit: b0f34d51fc Workload version: 10.0.100-manifests.4c0ca8ba MSBuild version: 18.0.2+b0f34d51f
Runtime Environment:
OS Name: debian
OS Version: 12
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/10.0.100/
.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.
Host:
Version: 10.0.0
Architecture: x64
Commit: b0f34d51fc
.NET SDKs installed:
9.0.307 [/usr/share/dotnet/sdk]
10.0.100 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 9.0.11 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.22 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Activity
colejohnson66 commentedon Nov 18, 2025
This is unfortunately the nature of serial ports. The
IsOpenproperty doesn't mean that the port exists; It means that you opened it and have yet to close it.Blackclaws commentedon Nov 18, 2025
@colejohnson66 This isn't entirely true. If you check the Windows implementation (https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialStream.Windows.cs#L239) IsOpen does depend on the current state of the event handler while the Unix version (https://github.com/dotnet/dotnet/blob/b0f34d51fccc69fd334253924abd8d6853fad7aa/src/runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialStream.Unix.cs#L391) only depends on whether you acquired a handle.
This does not cover the case where the serial port no longer exists while the Windows case should cover it.
Also that no errors are thrown when you write/read from a non-existent serial port on Unix is also a bug.
colejohnson66 commentedon Nov 18, 2025
The Windows implementation's additional check doesn't change the result; The event runner still runs if the port goes missing.
Yes, the read/write errors being swallowed is a bug. I was only talking about
IsOpen.Blackclaws commentedon Nov 18, 2025
Given that validating whether the handle is still valid shouldn't be a big ask I would say IsOpen not showing false for a serial port that went away is a bug as well for both implementations then.
On Linux a simple check is whether the actual device descriptor still exists and whether its inode is still the same. That check isn't overly expensive and could even be cached to only run once a second if needed.
dotnet-policy-service commentedon Jul 20, 2026
Tagging subscribers to this area: @dotnet/area-system-io-ports
See info in area-owners.md if you want to be subscribed.