Skip to content

fix: handle SIGINT in ErrorHandler #126

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

Merged
merged 1 commit into from
Mar 30, 2020
Merged

fix: handle SIGINT in ErrorHandler #126

merged 1 commit into from
Mar 30, 2020

Conversation

hdp617
Copy link
Contributor

@hdp617 hdp617 commented Mar 25, 2020

Currently, when running the Functions Framework in a Docker container by running docker run, one cannot stop the running container with Ctrl+C. This is because the Functions Framework doesn't handle SIGINT in the ErrorHandler. This change handles SIGINT in the similar fashion as SIGTERM i.e. close the web server and exit the process.

Currently, when running the Functions Framework in a Docker container by running `docker run`, one cannot stop the running container with Ctrl+C. This is because the Functions Framework doesn't handle SIGINT in the ErrorHandler. This change handles SIGINT in the similar fashion as SIGTERM i.e. close the web server and exit the process.
@hdp617 hdp617 merged commit de59809 into master Mar 30, 2020
@hdp617 hdp617 deleted the huy-handle-sigint branch March 30, 2020 18:03
@l0co
Copy link

l0co commented Jun 3, 2020

With this fix you can't now stop the server from the console (in Linux). After clicking CTRL+C it only says "Received SIGINT" forever. Exiting with CTRL+C works only after downgrading to 1.5.0.

@hdp617
Copy link
Contributor Author

hdp617 commented Jun 3, 2020

I couldn't reproduce this on my Linux machine. How do you run the Functions Framework?

@l0co
Copy link

l0co commented Jun 3, 2020

Using npx @google-cloud/functions-framework --target=webhookPublisher

I've checked once again and it seems it's something with this code:

        ['SIGINT', 'SIGTERM'].forEach(signal => {
            process.on(signal, () => {
                console.log(`Received ${signal}`);
                this.server.close(() => {
                    process.exit();
                });
            });
        });

To reproduce this problem after starting the server I need to make some requests to the function first, for example 10 quick requests one after another. I respond to them just with:

export function webhookPublisher(req: Request, res: Response) {
        res
            .status(400)
            .type("text/plain")
            .send("Some error message")
            .end()
}

Here is the log when I try to kill it with CTRL+C:

$ npx @google-cloud/functions-framework --target=webhookPublisher
Serving function...
Function: webhookPublisher
URL: http://localhost:8080/
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
^CReceived SIGINT
Error: Process exited with code 0
    at process.on.code (./node_modules/@google-cloud/functions-framework/build/src/invoker.js:396:29)
    at process.emit (events.js:189:13)
    at process.EventEmitter.emit (domain.js:441:20)
    at process.exit (internal/process/per_thread.js:168:15)
    at Server.server.close (./node_modules/@google-cloud/functions-framework/build/src/invoker.js:402:29)
    at Object.onceWrapper (events.js:277:13)
    at Server.emit (events.js:194:15)
    at Server.EventEmitter.emit (domain.js:441:20)
    at emitCloseNT (net.js:1609:8)
    at process._tickCallback (internal/process/next_tick.js:63:19)

If I don't do any request it exist immediately.

In 1.5.0 it exits immediately, even after requests.

But now I think there's the same problem in both 1.5.1 and 1.5.0 because the only difference is that 1.5.0 doesn't wait for anything and dies, while 1.5.1 waits for server stop. The problem seems to be with server.stop().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants