ECONNRESET errors when idling #318
Comments
|
One other detail - don't ask me why I thought to do this - but since I continue to see these reset errors in the log, I quickly compared the amount of time between each event and it looks to be approx. 17 minutes: 1:29PM - 1:12 = 17 Maybe this is a setting somewhere? |
|
It's quite possible that the LDAP server you're connecting to will time out idle clients. Subscribing to the |
|
@pfmooney OK I'll check into that. In the background, does LDAPJS pick up these errors and try to reconnect, or completely bails until I restart my Node process? |
|
While ldapjs had client options to automatically reconnect in the face of socket errors, they have not yet been documented. Alternatively, you can perform such actions manually by instantiating a new connection when your client encounters an error. |
|
As noted above, the documentation for the Client API doesn't mention auto-reconnecting or how to handle an eventual ECONNRESET from the server. I can't imagine an LDAP server that never closes or resets the connection, or never goes down. Appears to be option The documentation also does not mention how to close a connection, which is necessary if you are writing a small script that should gracefully shut down after doing its work. I looked in the source and appears this can be done with Both of these points would be useful to mention in the documentation. Thanks! |
|
👍 Thanks very much for doing the digging @tapmodo. So an over-simplified solution looks like: Job done - thanks guys! |
|
This doesn't seem to reconnect properly for me. Anyone else having issues? The program doesn't exit but it just hangs on any attempt to re-authenticate. |
|
@dustinsmith1024 - I've been having |
|
Where to add this entry reconnect:true and client.destroy()? Thanks in advance |
|
I have changed the LDAP idle timeout in AD, post that it looks fine, will keep monitoring. thanks. |
|
@saigop - I believe you put |
As per ldapjs/node-ldapjs#318 , sometimes you will need to call destroy to completely close a client connection so you don't idle error out after ~17 minutes.
|
@saigop "I have changed the LDAP idle timeout in AD, post that it looks fine, will keep monitoring. " what is AD?? |
|
@the1mills Active Directory |
|
Without using TLS, same issue. |
|
When I add the reconnect I get a: Err:OperationsError: 000004DC: LdapErr: DSID-0C090748, comment: In order to perform this operation a successful bind must be completed on the connection I think some insight into how we need to gracefully handle this in NodeJS would be helpful. Realistically we need to ask do we close the connection, do we let is close on its own, should we be destroying the connection in intervals? |
|
I've been looking into this more deeply and I'd love to see some responses. We added reconnect: true along with bind/unbind as we were seeing basically an LDAP break around 15m after starting the service. We still continue to see everyone's favorite error: [2016-05-23 22:04:44.068] [ERROR] Server - Exception ->Error: read ECONNRESETerrStack: Error: read ECONNRESET It's much more sporadic now with the exception that the re-connect and unbind ensure that we no longer see any issues because it automatically reconnects. A packet capture shows us that even though we did an unbind, we see the RST from our LDAP server, which leads to an exchange of SYN and ACH packets and once our NodeJS server and LDAP exchange two sets of ACH packets another RST ensues basically saying "send me something! no you send me something! okay we'll close now" At this point, this just looks like noise to me as everything works fine outside of that. |
|
I recently experimented with setting up my own LDAP connection pool using the npm package Basically I have the pool give me connections and then automatically unbind them if they age out thus completely avoiding the idle timeout issue that I experience with Active Directory. I have never found that |
|
The thing that I learned is that its not an idle session timeout. For some reason LDAPJS keeps trying to connect to LDAP even when no attempt to bind is occurring. |
|
any update on this issue? we are using the ldapauth fork library which build on top of ldapjs. It is suffering from this same issue due to this bug in ldapjs and here are the discussion: vesse/node-ldapauth-fork#23 |
|
+1 What's the proper way to close a client? Proper way to reconnect? Those sound like essential points that need to be documented please. Thanks. |
|
+3 |
|
This issue was opened a year ago, has this changed? edit: My current workaround is simply this: const ldapClient = ldapjs.createClient({
url: config.get('ldap.url'),
reconnect: true
})
ldapClient.on('error', err => {
logger.error(err.message)
})Once in a while I'll get a |
|
I've solved the problem removing the client definition out of the main node loop. So I'm building the client just when it's necessary and after the call I destroy it. app.post('/item', function(req, res) {
const ldapClient = ldapjs.createClient({
url: 'ldap://ldap.server.com:3880',
reconnect: false
});
...
res.on('end', function(result) {
console.log('status: ' + result.status);
ldapClient.destroy();
}); |
|
For some reason
is not documented, as far as I can tell. Should we call unbind() before destroy()? client.unbind(function(){
client.destroy();
}); |
|
Seeing this: The timing seems random. I'm on 1.4 |
|
destroy calls unbind internally |
|
I think this topic has been sufficiently covered in this thread. If someone would like to condense it into some better documentation and submit a PR that would be fantastic. I am closing this issue so I can continue triaging old issues. |
|
I just figured this out, at least in my use case. I was getting ECONNRESET. It turned out that the way my client was set up, it was hitting the server with an API call a ton of times really quickly -- and it only needed to hit the endpoint once. When I fixed that, the error was gone. |
|
Since I still had to deal with some diffrent errors using the fixes above I finally found a solution working out for me. const createClient = () => ldap.createClient({
url: config.ldap.URL,
reconnect: true,
});
let client = createClient();
const rebindClient = () => {
client.destroy();
client = createClient();
client.bind(config.ldap.BIND_DN, config.ldap.BIND_CREDENTIALS, (err) => {
if (err) {
console.error(err);
}
});
};
rebindClient();
client.on('error', (err) => {
if (err.errno === -4077) {
rebindClient();
} else {
console.error(err);
}
}); |
|
I have an application that add and remove groups in AD, and that uses ldapjs. I'm getting ECONNRESET error many times. For exemple, when I get econnreset error 5 times, i can listen for the error and call a function in my code that restart the execution. But sometimes I received econnreset error 30 times or more (consecutivelly), and my application couldn't restart.
Do you know how to stop getting econnreset error or how is the corret way to catch this error or how to correctly close ldap connections? |
|
Please include a minimal reproducible example |
and others
I'm trying to figure out the source of the error below, or how to catch it properly and mitigate it. I am using LDAPJS as part of an identity management pipeline to move user accounts from our ERP into Active Directory (connected over TLS with a self-signed cert). There is often idle periods in the database where no events are being dispatched, and in turn LDAPJS raises these exceptions when I assume it has nothing to do.
They only show up because of my
process.on('uncaughtException')handler which in turns logs the event and then auto-restarts the broker.Ideas?
The text was updated successfully, but these errors were encountered: