Skip to content

fork of long-running reaper and mysql and openssl and memory #132

Closed
donald opened this issue Apr 15, 2022 · 0 comments · Fixed by #133
Closed

fork of long-running reaper and mysql and openssl and memory #132

donald opened this issue Apr 15, 2022 · 0 comments · Fixed by #133

Comments

@donald
Copy link
Contributor

donald commented Apr 15, 2022

Currently, mxqd forks a reaper process for every user job which stays around until the user job is done. This has several problems:

  • To avoid the child from interfering with the sql server, the parent calls mysql_close() before the fork and mysql_connect() after. This generates unnecessary load on the mysql server. And the semantics are not well defined in the mysql documentation. We can not be sure that, that (all) sockets are closed and are not being leaked to the child, which would be a security problem in itself and might create new problems when the internal workings of the libraries are changed (e.g. in atexit() handlers).
  • Although the reaper calls mysql_library_end before exit, valgrind still shows unfreed memory (mysql->openssl). This in itself is not a problem, but a further hint, that the behavior of the library with cloned address spaces is unclear.
  • While a long-running reaper exists, any memory which mxqd modifies, needs to be duplicated. At the same time, any memory it frees still needs physical memory in the reaper. This is even true if mxqd is re-execed. So we needlessly sit on physical memory.

Maybe we should use exec() for the reaper processes to avoid unclear library semantics and memory duplication.

@donald donald mentioned this issue May 11, 2022
Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant