On Fri, Dec 13, 2019 at 08:47:49PM +0100, mj wrote: > > root@pf:~# ps aux | grep rsyslog > > root 11250 0.8 3.3 872116 274200 ? Ssl 15:37 2:26 > > /usr/sbin/rsyslogd -n > > root 23873 0.0 0.0 12780 968 pts/0 S+ 20:25 0:00 grep > > rsyslog > > root@pf:~# service rsyslog stop > > root@pf:~# ps aux | grep rsyslog > > root 23909 0.0 0.0 12780 1020 pts/0 S+ 20:25 0:00 grep > > rsyslog > > > root@pf:~# rm -f /usr/local/pf/logs/* > > root@pf9:~# lsof | grep /usr/local/pf/logs > > snmptrapd 23941 root 3w REG 8,1 > > 23 67605574 /usr/local/pf/logs/snmptrapd.log > > and yes: the file snmptrapd.log is the exception, all other files (20, 25 of > them) are gone, remain gone, and are not listed in lsof as open.
So, it sounds like you want to kill snmptrapd (instead of, or in addition to, killing rsyslogd) before you unlink these log files. If this were a traditional daemon, I might give the alternative answer, "Or you could truncate the files instead of unlinking them." But it seems like snmptrapd is doing something *weird*, perhaps storing its own copy of the logs in memory, and rewriting them to files when it discovers that they are not on disk. So, for this particular case, truncating the log files may not work. But killing snmptrapd should.
