This is primarily a warning to others. On individual level, it requires just a vigilant admin eye and a possibly manual restart command. On the package level, it could be mitigated by changing a "reload" command by "restart". WONTFIX would also be a legit verdict, in my opinion. I have upgraded the world, have run dispatch-conf, but haven't restarted syslog-ng afterwards, which is a necessary precondition to this issue. I also run logrotate. Logrotate has a postrotate action to "reload" syslog-ng. This time it didn't produce the intended effect because the config file was rejected as of a format version the process didn't know. So syslog-ng process continued to write into the "retired" log file. Nov 26 12:19:22 decent start-stop-daemon[3293]: Will stop PID 1622 Nov 26 12:19:22 decent start-stop-daemon[3293]: Sending signal 1 to PID 1622 Nov 26 12:19:22 decent syslog-ng[1622]: WARNING: Configuration file format is newer than the current version, please specify the current version number (3.30) in the @version directive. syslog-ng will operate at its highest supported version in this mode; config-version='3.33' Nov 26 12:19:22 decent syslog-ng[1622]: Error reloading configuration; reason='Syntax error parsing configuration file'
Started to get cron errors about this a month ago, finally figured its time to get to the bottom of this and found this... anyway instead of syslog-ng restart i went with: if [ -s "/run/syslog-ng.pid" ] ; then /bin/kill -HUP $(cat "/run/syslog-ng.pid") fi i will see with weekly rotate if its fixed or not :)
kill -HUP does not work, still get whiny emails about auth.log on logrotate.
I thought it's a good practice to call something like restart-services after @world upgrades. You may run into trouble without doing so.
