Every now and then you'll notice a log message or two being dropped when the system logs are rotated. I notice it on my mail server (which is very busy most of the time); I've heard others mention it with WU-FTPD. Consider: most programs write to the logs using the named pipe /dev/log. When sysklogd is restarted, it recreates /dev/log under a new inode. This presents a race condition. If, in the time between openning /dev/log and writing to it, the logs rotate, the sending program will use the old inode but sysklogd will only be listening on the new one. Two common services which exhibit vulnerability to this race on a regular basis are Sendmail and WU-FTPD. My proposed solution would be to add some method to instruct sysklogd to rotate the logs without openning a new /dev/log inode. This could be done with an external signal; which would work well with the current logrotate scheme. But I'm anal about precision .. I just *HATE* seeing a stray message from another day in my logs .. so what I've done locally is hack sysklogd to do the rotation all on its own, exactly at midnight. My changes are extremely local and have no other schedule than local- midnight, and use my local naming conventions, so I'm not providing them.
Just closing out old bugs here - this one is definitely fixed in current versions of syslogd. syslogd preserves the open unix sockets when it receives SIGHUP, and reopens all its log files.