From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
I've noticed this on different Red Hat & Fedora versions.  
It seems snmpd would need to be restarted in order to prevent it from
logging to an archived log file after logrotate runs.  

The following is what I have done on my servers to remedy the
situation.  This will restart snmpd if it is running at the time,
causing it to begin logging to a "new" snmpd.log file.  

--------
Modify /etc/logrotate.d/snmpd to appear as...  
(Note, this is adding three lines, "postrotate" thru "endscript")

/var/log/snmpd.log {
    notifempty
    missingok
    postrotate
        /sbin/service snmpd condrestart 2> /dev/null > /dev/null || true
    endscript
}

--------


Version-Release number of selected component (if applicable):
net-snmp-5.1.1-2

How reproducible:
Always

Steps to Reproduce:
1. Install & enable snmpd
2. Query your machine via snmp
3. Allow logrotate to rotate snmpd logs as usual
4. Query your machine again via snmp
5. Look at log files (/var/log/snmpd.log*)


Actual Results:  Originally logs to /var/log/snmpd.log.  
After log rotation, continues to log to the same inode, which has
become a different filename (/var/log/snmpd.log.1).  

Expected Results:  Logging should have gone to the new "snmpd.log"
file after rotation.  

Additional info:

-rw-r--r--    1 root     root          169 Jun  1 18:00 snmpd.log.1
-rw-r--r--    1 root     root            0 May 22 00:03 snmpd.log

(Log rotation moved original snmpd.log to snmpd.log.1, then created a
new snmpd.log...  meanwhile snmpd continues to write to the
snmpd.log.1 file, because it kept the same inode/filehandle when it
was moved).