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: Will stop PID 1622
Nov 26 12:19:22 decent start-stop-daemon: Sending signal 1 to PID 1622
Nov 26 12:19:22 decent syslog-ng: 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: 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")
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.