0

I asked this question in Unix & Linux but I think it actually fits better here.

Currently, I use the following logrotate.d configuration 

/var/log/messages 
{
    daily
    compress
    rotate 7
    postrotate
            /bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

However, I see in the official logrotate example in the syslog-ng repository, instead of doing a kill -HUP, they do a reload, eg: 

/var/log/syslog.log {
   rotate 7
   daily
   compress
   postrotate
      /etc/init.d/syslog-ng reload >/dev/null
  endscript
}

Is there a significant difference between these two methods, that would make their way work but my way not work, or would you expect there to be some other problem? This is a pretty old syslog-ng version, so I'm not sure if that could be related as well.

For additional context, here is the reload function from my version of syslog-ng's init script. 

reload()
{
        verify_config
        echo -n $"Reloading syslog-ng: "
        killproc syslog-ng -HUP
        RETVAL=$?
        echo
        return $RETVAL
}

I did check lsof, free memory, and more when the system was in a failed state and did not notice anything overly suspicious with the state of the system.

Jbart
  • 1
  • 1
  • Killing syslog-ng can result in losing messages, depending on its load and configuration. Reloading should avoid most of these problems. – Robert Fekete Jul 12 '17 at 13:49
  • Yeah, but doesn't the reload effectively do the same thing? It also kills the same PID. From the strace of doing the reload: kill(10097, SIGHUP) = 0 – Jbart Jul 12 '17 at 15:22
  • AFAIK, reload saves the information it can to avoid loosing messages (for example, messages in memory buffers, and so on) – Robert Fekete Jul 14 '17 at 10:04
  • Tested out this change, didn't work unfortunately. Interestingly, we only see this problem happening on one server that has a large load. The investigation continues! – Jbart Jul 17 '17 at 12:46

1 Answers1

0

The problem was not related to logrotate, and the issue appears to be fixed by updating to a newer version of syslog-ng (to 3.9.1). I think the root cause was a bug caused by the amount of load on the server. I could tell it wasn't a problem with the postrotate as both examples successfully reloaded the service, and on the older version changing between those did not ultimately change the crashing behavior.

Jbart
  • 1
  • 1