Can't run or debug serial port code on Ubuntu Linux

Should have added, OS is Kubuntu 24.10, and that the same behaviour happens on two *very* different machines with the same OS.

Dmitry Kazantsev: No, this makes no difference at all, the problem persists. JetBrains opened a support request, asked me whether starting from console fixed it, and I said “no”. So they closed the support request and marked it “solved”. What?

It works if run with sudo. There is something weird about the way rider executes - does the run or debug process run as a different user? If so that would explain the issue with permissions. I can't fix this by simply changing the port permissions as I'm using USB serial ports, so the permissions will reset each time I log out or reboot. I don;t like doing this work as sudo as it's a security risk. If the run/debug executes as a different user or something can you explain so I can see if there is a way to assign permissions to the process/user?

Hello Phil,

I see your another response (it didn't reach the current thread for some reason, we are looking into it. Apologies for that occasion). 

Rider doesn't use different user for running projects. Since it runs fine when Rider is launched elevated, the most likely issue is missing permissions for Rider (as it runs in a slightly different context compared to your terminal session).

At this time, I suggest trying this:

• Download and unarchive Rider binaries from the Download page;
• Try both options to check if anything helps:
  •  /bin/bash -l -i -c {unarchivedRider}/bin/rider.sh;
  •  /bin/bash -l -i -c {unarchivedRider}/bin/rider;
  • (then check if issue occurs in that way);
• Try launching your app from Rider-bundled terminal using cd {projectPath}; dotnet run;

• Compare env variables Rider receives (by launching sample console app) with env output in your terminal. Tell me what difference you observe.

  foreach (DictionaryEntry env in Environment.GetEnvironmentVariables())
       {
           Console.WriteLine($"{env.Key}: {env.Value}");
       }

Whether it helps or not, would you mind sharing additional information as described below?

• You mentioned the issue doesn't persist in Visual Studio. Does the issue persists in Rider on Windows?
• What is the way you usually launch Rider and how did you install Rider?
• What is `which dotnet` output in linux terminal (outside Rider)?
• What .NET CLI executable path is set in Settings | Build, Execution, Deployment | Toolset and Build?
• How exactly does your app opens a port (share a sample code snippet if possible); 
• How exactly did you configure corresponding permissions for opening ports?
• Would you mind sending us Rider logs (Help | Collect Logs and Diagnostic Data) through our Uploads server? I would appreciate it if you could also share a recording that demonstrates the issue (please share Upload ID);

Have a nice day!

OK, so here we go….  thanks for the response.

What fixes it is to put a delay in the code. The issue seems to be around startup. If the serial port is instantiated and then opened in the loaded event of an Avalonia window, we will get the issue but only when used in debug mode.

If, instead, I add a timer to the loaded event and instantiate and open the port from that, it works. A delay of around 0.5 seconds is needed. This was figured out on another PC, both fast machines (initially a Core i9-12900(? i9-12xxx anyway) and now on a Ryzen 9800 machine). I can reproduce it without Rider under Linux if I move the port instantiation into the display initialisation code or right up into the program.cs code.

I think you can close this as something few people will encounter but it's well worth keeping a note of.

To specifically answer your questions…

1. This doesn't happen on Windows with Rider or VS.

2. I usually launch Rider from the start menu (this is Kubuntu 24.10).

3. /usr/bin/dotnet

4. Code. The fail is on the Open.

_serialPort = new SerialPort(_settings.SerialPort, 9600, Parity.None, 8, StopBits.One);
_serialPort.Open();

5. The user is added to the dialout group

6. Recording is a fair bit of work, but I think we can say it's not a Rider issue, probably a .Net issue on Linux, and for some weird reason Rider exacerbates it, so that is probably not needed. The delay in code will solve the issue and I can isolate it to Linux hosts. If I get some time I'll try this on a slow box like a Raspberry Pi and see how the issue behaves there, though Raspian is another Debian based distro. I don't use any other base distro types.

FYI, re the code above, _settings.SerialPort is just a string variable loaded from a config file or selected from a dropdown.

Yes, I replied by email. My apologies if that was the wrong way to do it. I wasn't thinking, I guess.