Otdfbt

Below is my log rotation configuration for /var/log/messages.

/var/log/messages

 rotate 4
 size 100M
 missingok
 notifempty
 compress
 delaycompress
 sharedscripts
 postrotate
 ifconfig eth0 

I ended up in a scenario where logrotate created messages.1 where my previous logs are copied and rsyslog is still writing into messages.1 (might be because of delaycompress). Now messages file is created newly when log rotation happened it is of size Zero.

Since I have huge logging enabled for my application and rsyslog is still writing into messages.1, it became more than 3G while messages file being zero.

Any wrong with my configurations or do i need to enable/disable certain logrotate features to never end up in this kind of scenario ?

# logrotate --version 
logrotate 3.8.7

Try manually if such command line youre using actually reloads rsyslog. Test it by renaming messages to messages.x and touch messages plus chmod/chown it to same permissions as messages originally and then run this kill command, see if rsyslog actually starts using new file. If not, perhaps something wrong with that command. Is pid correct in such pidfile? Is pidfile present at all?

Anyhow, few more to try, debian uses these for example:

systemctl kill -s HUP rsyslog.service
invoke-rc.d rsyslog rotate

And ofcourse, to debug logrotate, there is

logrotate -vf /etc/logrotate.conf

which could possibly indicate some issues with logrotate config.

In the end, there is some kind of simple debugging, to see what gets executed:

...
postrotate
echo "before ifconfig" >> /tmp/logrotate.debug
ifconfig eth0 | grep 'Device not found' &>/dev/null
echo "after ifconfig" >> /tmp/logrotate.debug
if [ $? != 0 ]; then
 echo "inside if" >> /tmp/logrotate.debug
 kill -HUP $(cat /var/run/rsyslog.pid) > /dev/null
else
 echo "inside else" >> /tmp/logrotate.debug
 kill -HUP $(cat /var/run/rsyslog_1.pid) > /dev/null
fi
echo "at endscript" >> /tmp/logrotate.debug
endscript
...