I am getting a warning when I make requests against my aws-serverless-express server. I run the server using the serverless offline plugin as well. The warning reads as follows:
WARNING: Attempting to listen on socket /tmp/server0.sock, but it is already in use. This is likely as a result of a previous invocation error or timeout. Check the logs for the invocation(s) immediately prior to this for root cause, and consider increasing the timeout and/or cpu/memory allocation if this is purely as a result of a timeout. aws-serverless-express will restart the Node.js server listening on a new port and continue with this request.
Any ideas what's happening here? Each further request I make, the socket error increments, so if I've made two requests I get two warnings, if I make three requests I have three warnings and so on..
This is likely as a result of a previous invocation error or timeout. Check the logs for the invocation(s) immediately prior to this for root cause, and consider increasing the timeout and/or cpu/memory allocation if this is purely as a result of a timeout
Hi @Alex-Mann, did you check the logs?
Hey @brettstack, I do have SLS_DEBUG=* on, but I don't see anything particularly telling. Even when I shut down the server with ctrl c the incrementing still occurs.
If I go into /tmp folder, I see server0.sock .... server#.sock (depending on the number of invocations).
In my /tmp folder, a new server#.sock is created for each invocation. This causes the warnings. I can remove them all and then the first request does not trigger the warning, but each invocation after the very first does trigger the warning.
I see. I didn't realise this was during local development. The example comes with a light script for local development which kills the socket in those cases. Maybe you can apply something similar https://github.com/awslabs/aws-serverless-express/blob/master/example/scripts/local.js
@brettstack The cleanup script isn't a good workaround for us because we are running automated testing where the workflow is standup the local server, hit it several dozen times (testing each endpoint via swagger spec) then shutting down the server.
@Alex-Mann thought you might want to know how we've addressed the issue in our environment, we call server.close after context.succeed is called. I've submit a PR to provide this fix back to the community.
I'm having the same issue using the serverless & serverless-offline packages with aws-serverless-express.
I've tried @jeremygiberson branch and it does fix the issue, but I see in #103 it doesn't work in lamdba. Did anyone work out a way to implement this fix without breaking AWS lambda functionality?
@jeremygiberson thanks for this.
@munkyjunky I have temporarily adopted serverless-http and it works well with serverless-offline.
If I have some time I will look into how they work with closing sockets and see if there is something that can be inspired to work with this package.
Fixed in v3.1.1
Most helpful comment
Fixed in v3.1.1