https://bugs.winehq.org/show_bug.cgi?id=53588
Bug ID: 53588 Summary: listening tcp socket is removed after some time Product: Wine Version: 3.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: winsock Assignee: wine-bugs@winehq.org Reporter: marcsamuro@gmail.com Distribution: ---
Hi,
i'm testing a rather simple background windows application that uses only disk, network, memory, processes and threads. When starting, the application opens a pair (ip4 & ip6) of listening socket on TCP port 80, and another pair of listening sockets on UDP port 13000. They are always kept open.
At first everything works fine, all listening ports appear when doing netstat and the application works great :
netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 15897/wineserver64 tcp6 0 0 :::80 :::* LISTEN 15897/wineserver64 udp 0 0 0.0.0.0:13000 0.0.0.0:* 15897/wineserver64 udp6 0 0 :::13000 :::* 15897/wineserver64
However, after some time (a few hours ?) suddenly the tcp listening sockets do no longer appear when doing netstat :
netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name udp 0 0 0.0.0.0:13000 0.0.0.0:* 15897/wineserver64 udp6 0 0 :::13000 :::* 15897/wineserver64
The UDP listening socket still appear, and the application responds fine to requests on the UDP port. However the TCP (http) connection on port 80 does not respond anymore.
What could be the cause of that, what can i test to pinpoint the problem ? I saw the sockets are owned by wineserver64 so i guess they are managed by wine. Why does only the TCP disappear and not the UDP ? Is there a timeout or some other settings ?
On pure Windows, the application works fine since years, so it must be some problem with linux or wine.
I'm using wine-3.0 (Ubuntu 3.0-1ubuntu1)
i'm starting the app with the command line :
nohup wine planet_server.exe &
Thank you.
https://bugs.winehq.org/show_bug.cgi?id=53588
marc samuro marcsamuro@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|3.0 |7.0
--- Comment #1 from marc samuro marcsamuro@gmail.com --- i'm doing test with wine-7.0 now, and found a clue:
tcp sockets are owned by wineserver, whereas udp sockets are owned by the windows app.
That explains the difference, but why does wineserver drop them ?
$ netstat -nap Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28183/wineserver tcp6 0 0 :::80 :::* LISTEN 28183/wineserver udp 0 0 0.0.0.0:13000 0.0.0.0:* 28181/planet_server udp6 0 0 :::13000 :::* 28181/planet_server
https://bugs.winehq.org/show_bug.cgi?id=53588
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |minor CC| |z.figura12@gmail.com
--- Comment #2 from Zeb Figura z.figura12@gmail.com --- I don't know how netstat is determining who "owns" the sockets, but that difference doesn't make much sense. Wine sockets are created in the wineserver process but then shared with the client, so both processes should end up holding an fd to the same socket at any given point.
I also don't have any idea why the TCP sockets would cease to respond after a while.
Is it possible to share the program itself, or link to a free download?
Or, failing that, can you try to get a +server,+timestamp log? If it takes hours to reproduce it may become prohibitively large, though...
https://bugs.winehq.org/show_bug.cgi?id=53588
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|minor |normal
https://bugs.winehq.org/show_bug.cgi?id=53588
--- Comment #3 from marc samuro marcsamuro@gmail.com --- ok i'm back.
I've been running two occurences of the server since 3 weeks now with wine-7.0 and I almost hoped the problem would disappear, but it's back :(
One of my two servers is still fine, the other does not respond anymore on port 80 (but works fine on the other tdp port so i know the process is alive and well). And when looking with netstat -an the tcp listener on port 80 just disappeared.
I'm running at least 10 of these servers on pure Windows servers since years so i can eliminate a problem with the Windows software itself. It can only be Wine suddenly closing (or removing ?) the tcp listener.
This is for me a blocking issue, i cannot move from Windows to Unix servers if suddenly the website stops responding.
https://bugs.winehq.org/show_bug.cgi?id=53588
--- Comment #4 from marc samuro marcsamuro@gmail.com --- ok i think now we're getting somewhere, i have additional log info.
the application does these 3 calls when accepting a tcp call :
s = accept (listener setsockopt (s, WSAEventSelect (s,
and one of these 3 seems to return WSAENOTCONN 10057 to signal that the connection is already closed.
It seems that in Windows these 3 calls never fail. Windows probably does not test this early that the connection is down.
https://bugs.winehq.org/show_bug.cgi?id=53588
--- Comment #5 from Zeb Figura z.figura12@gmail.com --- (In reply to marc samuro from comment #4)
ok i think now we're getting somewhere, i have additional log info.
the application does these 3 calls when accepting a tcp call :
s = accept (listener setsockopt (s, WSAEventSelect (s,
and one of these 3 seems to return WSAENOTCONN 10057 to signal that the connection is already closed.
It seems that in Windows these 3 calls never fail. Windows probably does not test this early that the connection is down.
You don't have any idea which call is failing, though? Are the return values being tested, or just WSAGetLastError()?
Which socket option is being set?
We should never end up returning WSAENOTCONN from WSAEventSelect(), but we might propagate an ENOTCONN from the host for accept() or setsockopt().
-
WineHQ Bugzilla