Skip to content
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

Remote client connection stays in CLOSE_WAIT state #3358

monetdb-team opened this issue Nov 30, 2020 · 0 comments

Remote client connection stays in CLOSE_WAIT state #3358

monetdb-team opened this issue Nov 30, 2020 · 0 comments


Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2013-09-04 09:11:45 +0200
From: @bartscheers
To: SQL devs <>
Version: 11.15.11 (Feb2013-SP3)
CC: @njnes

Last updated: 2013-09-27 13:47:18 +0200

Comment 19118

Date: 2013-09-04 09:11:45 +0200
From: @bartscheers

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0
Build Identifier:

When mclient tries to connect to a remote database, but provides an invalid user or password, the server will have a connection that stays in CLOSE_WAIT state.

Reproducible: Always

Steps to Reproduce:

  1. create (empty) db on remote server
  2. access from client: mclient -hremote.server -dremotedb -p50000
  3. provide an incorrect password (or username) to get
    InvalidCredentialsException:checkCredentials:invalid credentials for user 'monetdb'

Actual Results:

On the server it shows (netstat -ap):
tcp 1 0 remote.server:50000 client:42231 CLOSE_WAIT 30210/mserver5 t

Expected Results:

No entry

This also happens when another schema/user/pw than the default sys/monetdb is in place

Comment 19125

Date: 2013-09-04 14:37:45 +0200
From: @njnes

for now solved by closing the streams properly after login failures. This gives slightly different time_waits then normal (successfull) connections as those
are first closed by the client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant