Bug #44300 mysqld does not establish a new session (posix setsid)
Submitted: 15 Apr 2009 15:53 Modified: 19 Apr 2011 14:47
Reporter: Paul Green (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:5.0.75, 5.1, 5.1-telco OS:Any
Assigned to: CPU Architecture:Any
Triage: Triaged: D5 (Feature request)

[15 Apr 2009 15:53] Paul Green
Description:
The mysqld executable does not follow the usual "daemonizing" convention of forking and establishing a new POSIX session.  I can find code in ndb (ndb/src/common/portlib/NdbDaemon.c and ndb/src/cw/cpcd/Process.cpp) and in the mysqlmanager (server-tools/instance-manager/mysqlmanager.cc) that calls setsid, and performs the other usual "daemonizing" steps.  But I can't find anything in mysqld itself.

I have also looked at version 5.1.33 and get the same results there. I have the forums and find no mention of this issue there.  I found bug #43559 but that refers to a problem in the ndb code, not mysqld.

The issue is that my OS won't clean up the process that started mysqld because they are members of the same session; if mysqld would detach and create its own session, then it would clean up the (old) parent. I suspect there are other issues as well, such as receiving signals for the controlling terminal; I just haven't encountered them as yet.

Is this an oversight or is there a reason why this isn't done?  Or am I missing something?

ref: http://en.wikipedia.org/wiki/Daemon_(computer_software)

Thanks, PG

How to repeat:
Build mysqld.  Look for references to the setsid function.

Suggested fix:
Grab the NdbDaemon_Make function from ndb/src/common/portlib or the daemonize function from server-tools/instance-manager/mysqlmanager.cc.  Call it in the main() function of sql/mysqld.cc.
[13 Dec 2009 13:28] Sveta Smirnova
Thank you for the reasonable feature request.

Problem exists in 5.1-telco tree as well.
[19 Apr 2011 14:47] Paul Green
I just examined the source code of Version 5.6.2-m5 (the newest version I can find) and I don't see any sign that this issue has been resolved.

I'm surprised that other POSIX implementations haven't complained about this issue. Surely we aren't the only OS that is affected.