26 signal handling

[gwolf-011235]

Summary (updated)

Summary was updated with new functionality: register specific signals; difference between quick and graceful shutdown. Additions marked with (NEW)

1. New signal handler
2. Incorporate signal handling in server
3. New Connection state: Idle
4. New ServerShutdown function
5. Make Server::run() a non-member function
6. Remove toString() in initVirtualServers()

1. Signal handling

• create signal handler which simply sets the value of the global std::sig_atomic_t g_signalStatus to the signal number
• Signal handler should have only limited functionality. Setting a global variable is standard
• added converter from sigNum to sigName function for readability
  • (NEW) converter only converts used signal names.
• added clang-tidy check-option for global variables: must have prefix g_

2. Incorporate signal handling in server

• Global variable g_SignalStatus is used in Server loop: as long as it is 0 (no signal received) the loop continues
• Usage: register signal to signalhandler. When the registered signal is caught it updates g_SignalStatus, breaking the loop.
• (NEW) function registerSignals() registers the following signal to signalhandler:
  • SIGINT (quick shutdown)
  • SIGTERM (quick shutdown)
  • SIGHUP (quick shutdown)
  • SIGQUIT (graceful shutdown)
• (NEW) Only if received signal is SIGQUIT the function shutdownServer() is called, which performs a graceful shutdown. Every other signal just exits the event loop, which eventually calls the destructor of Server performing a quick shutdown

3. Connection::Idle

• new state of Connection: Idle
• needed for graceful shutdown
• initial state of a connection when newly accepted or
• established connection finished (response send), but kept alive
• state changes as soon as it tries to send request header

4. serverShutdown function

• when the server breaks out of the main loop after signal SIGQUIT, it tries to do a graceful shutdown with serverShutdown():
  • closes all opened virtual servers, then
  • closes all idle connections and removes closed ones
  • enters another event loop, with additional condition: as long as there are still active connections
  • (NEW) This second loop is active as long as the last signal received is SIGQUIT. Another signal breaks out of second loop (interrupting graceful shutdown)
• added tests

5. Server::run > runServer(Server& server)

• Server::run was the last member function of server, which did logic
• extracted as free function to make Server a pure value object

6. Remove toString

• toString() was used to convert port from num to string
• ConfigFile changed, function call was not needed anymore
• Also adapted test, and added more.

[gwolf-011235]

Calls up memories of the struggles we had with the signal handling in minishell.

That reminds me: since we do use fork() for CGI, we would need to check which signal handler is registered, and if we need to change it. Also in case of sudden shutdown (aka interrupting the graceful shutdown - send signal two times) we would need to kill all spawned child processes. Something to keep in mind after CGI was added > should I open issue?

You tested it by trying out Ctrl+c and Ctrl+d?

Right now only SIGINT is registered, since it's easy to test (ctrl+c) Ctrl+d doesn't send a signal per se, it sends char EOF. Since we don't do input handling we don't care about it :D

[u413-284-si]

Yes, please create an issue for this.

[gwolf-011235]

Yes, please create an issue for this.

Tracked as issue #60

[gwolf-011235]

Regarding which signals should be handled:

@u413-284-si found these resources:

• https://nginx.org/en/docs/control.html
• https://rafallorenz.com/go/handle-signals-to-graceful-shutdown-http-server/

where

• SIGINT and SIGTERM perform fast shutdown,
• SIGQUIT performs a graceful shutdown (finish serving open connections)
• SIGHUP performs a configuration reload.
• (additional signals, which are even more specialised)

Since we're not expected to daemonize our server (see the informative man daemon(7) ), I would suggest to not implement reloading of config. Even we do want, I would track it as extra issue and not implement it in this PR.

However I will implement

• SIGINT and SIGTERM as fast shutdown (just break out of event loop, destructor handles the rest).
• SIGQUIT as graceful shutdown (graceful shutdown is already implemented so simple if condition).
• SIGHUP gets fired if the terminal closes, so I would handle it the same as SIGINT (fast shutdown)

[gwolf-011235]

Updated with new functionality (in summary, additions marked with (NEW))

• register signals: SIGINT, SIGTERM, SIGHUP, SIGQUIT
• quick and graceful shutdown