-
-
Notifications
You must be signed in to change notification settings - Fork 171
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
system-wide proxy cannot create a connection ([Errno 9] Bad file descriptor
)
#3939
Comments
Please try first on a supported OS like Fedora, I do not have ArchLinux to test. |
Oh, I did not know that ArchLinux is not supported. Does this mean that you are not interested in helping ArchLinux users either? I don't have have any experience with Fedora ecosystem. If you are interested I can prepare a Docker image or bisect. |
https://github.com/Xpra-org/xpra/wiki/Platforms
No it means that my "free" time is very limited: https://xpra.org/list/2023-July/002987.html |
I feel sorry 😐. I will open a PR after I have a rough idea where the problem could be. My OS is not supported so I want to leave space for more important issues. Regarding project management changes: I have been also asking myself how you handle this large project alone. I don't have experience with sustaining open source projects. What I saw in another open source project is:
|
Interestingly, the missing attributes had been flagged in: #3930 (comment). |
The |
I want to use the system-wide proxy to create a new Xpra session via the HTML5 client. The client fails after a timeout with
connection failed, invalid address?
.Steps to reproduce the behavior:
xpra.service
with the following exception:--ssl=off
.f133a43
)I also tried downgrading to 4.4.6. The problem does not exist in 4.4.6. I can bisect if needed.
Remarks:
pam-selinux
is not installed. Is SELinux required for the system-wide proxy? Maybe/etc/pam.d/xpra
must be reconfigured, however this is another issue.xpra.service
uses--tcp-auth
evenman xpra
states that--tcp-auth
is deprecated andbind-tcp=0.0.0.0:14500,auth=...
should be used instead. Is the notion of arguments inxpra proxy
are slightly different? However I don't think usingtcp-auth
is related to this issue.Server logs (auth, proxy, websocket, protocol):
The text was updated successfully, but these errors were encountered: