According to the manual, FLUSH LOGS is supposed to:
Closes and reopens all log files. If binary logging is enabled, the sequence number of the binary log file is incremented by one relative to the previous file. On Unix, this is the same thing as sending a SIGHUP signal to the mysqld server (except on some Mac OS X 10.3 versions where mysqld ignores SIGHUP and SIGQUIT).
If the server is writing error output to a named file (for example, if it was started with the –log-error option), FLUSH LOGS causes it to rename the current error log file with a suffix of -old and create a new empty log file. No renaming occurs if the server is not writing to a named file (for example, if it is writing errors to the console).
There is a bug, however. In the case when the error log writes to a non-default path, FLUSH LOGS actually does not work as specified for the error log. I have not seen issues with binary logs in non-default paths, but we just ran into this issue on a client site and it threw us for a big loop, and we had to wait for an appropriate downtime window so we could actually restart the server so the logfile was rotated and written to appropriately.
The bug description is here: http://bugs.mysql.com/bug.php?id=19642
and is actually a duplicate of: http://bugs.mysql.com/bug.php?id=6061
This is a pretty serious bug in my opinion, and it’s only fixed in MySQL 5.1 — there are no patches or fixes for 4.1 or 5.0.