| Bug #22309 | FileLogHandler::createNewFile() isn't thread safe - may loose log messages | ||
|---|---|---|---|
| Submitted: | 13 Sep 2006 12:59 | Modified: | 3 Nov 2006 13:15 |
| Reporter: | Stewart Smith | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Cluster: Cluster (NDB) storage engine | Severity: | S3 (Non-critical) |
| Version: | 5.0,5.1 | OS: | |
| Assigned to: | Assigned Account | CPU Architecture: | Any |
[13 Sep 2006 13:12]
Stewart Smith
Initially, freopen() looked like a possibility. But, it seems that on some FreeBSD systems, freopen() hasn't been thread safe (although it's a FreeBSD bug). http://lists.freebsd.org/pipermail/freebsd-threads/2005-December/003333.html and, the POSIX gods tell us "Failure to flush or close the file descriptor successfully shall be ignored.", so we could leak file descriptors or not get an error back to the user about being unable to finish their log file (however we do that without a log). So a mutex seems to be the ticket.
[3 Nov 2006 4:32]
Stewart Smith
same patch as for BUG#22313
[3 Nov 2006 13:15]
Stewart Smith
marking as duplicate of BUG#22313
Description: 00165 m_pLogFile->close(); 00166 if (!File_class::rename(m_pLogFile->getName(), newName)) 00167 { 00168 setErrorCode(errno); 00169 rc = false; 00170 } 00171 00172 // Open again 00173 if (!m_pLogFile->open()) 00174 { 00175 setErrorCode(errno); 00176 rc = false; 00177 } Writes to log could come in between close and open How to repeat: be unlucky. Suggested fix: lock somehow.