Issue with .NET Core Named Pipes on Linux (address already in use)

Question

I am looking into using named pipes to control some aspects of a .net core application running under linux (ex: triggering a save, shutdown, etc).

I am trying to create a NamedPipeServerStream inside the application, however it always fails with the following message: Address already in use (I tried different names, nothing helps).

I have also attempted creating a temporary pipe using /tmp/somepipename, however this also fails with the following message: The name of a pipe on this platform must only include characters valid in file names.

From looking at the .NET Core tests for named pipes, this shouldn't be an issue as they also use Path.GetTemporaryFileName() to generate a temporary pipe

Here is the usage: NamedPipeTestBase.cs

And here is the implementation of GetUniquePipeName: PipeTestBase.cs

Just in case, here is the code I am using (one liner, pretty simple):

_pipe = new NamedPipeServerStream("somepipename", PipeDirection.InOut,1);

Am I doing something wrong, or are Named Pipes not fully implemented for Linux yet?

Answer 1

Regarding the error:

Unhandled Exception: System.PlatformNotSupportedException: The name of a pipe on this platform must only include characters valid in file names.

This is the expected behavior. Your input (/tmp/somepipename) is a fully qualified path and not a file name. An example of a valid file name would be: some.pipe

The forward slash is valid when using named pipes on some platforms though. That's why you can see the CoreFX test class has the check on IsInAppContainer before prepending the slash. IsInAppContainer's code shows that if it's not Windows, it would always return false and not add the slash.

I've tested the client server connection via named pipes on a MacOS 10.12.6 and CentOS 7.2 and it worked as expected. You can actually see some Unix specific implementation of PipeStream on GitHub.

I believe the error raised:

Address already in use

Comes from your program trying to bind to a IP/port combination already in use. Could that be the case? If not, please provide your solution so I can troubleshoot it on a Linux machine.