This repository has been archived by the owner on Jan 15, 2019. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
modify db connection error handling in the ido2db child to prevent en…
…dless forks #2458 when the handle_client_connection function is being run, reading from the socket, and then passing that to a dynamic buffer, the check_for_client_input call will happen, and then checking if the idodmod client should be disconnected due to the gotten data. within handle_client_input, it will be made clear that the initial db_hello needs to take place. problem at this stage is, that a non-existing database connection will cause this function to fail, calling its own wipe threads/memory/connection functionality plus a hard call to _exit(0) which will leave the socket unclosed and open - and therefore leading to a new handshake with idomod on the next loop run. within db_hello, the db_version_check takes place as well, where errors are ignored (cause return value not taken into account) plus the instance name check depends on a valid db connection, which will lead into an error on db_query call (where a call to db_reconnect happens, which will fail too). the handle_db_error function will now set disconnect_client=IDO_TRUE, but after not fetching the correct values, the else condition will match, trying to hard-exit the child in process. this exit will lead into the mentioned leftopen socket, leading to multiple forks on new connections - while the childs are left in defunct or socket_wait, as their file descriptor is still open on the socket - which is still in use by the first and following n forks. so this is a valid race condition amongst the first false exit leaving the socket open, as well as the others not getting rid of it after their exit calls as well. the proper fix for this brainfuck is merely to check the return values of each function call in this row, and bailing early without wiping anything nor exiting the child. this is being left alone to the handle_client_connection function, which will normally decide upon disconnect_client==IDO_TRUE? if it is time to disconnect idomod AND close the socket. plus terminate the threads and clean the memory. same goes for the housekeeping thread as well, this is not even allowed to call _exit(0) on its main process, and therefore will return an error on db connection failure too, whereas this thread connection polls in 5sec interval, if a valid connection and/or instance name is available. overall, this is not the best fix, but it is more clean than closing the socket before invoking an uncontrolled call to _exit(0) - which probably would have saved the hassle as well - did not try though. refs #2458
- Loading branch information