{"action":"created","issue":{"url":"https://api.github.com/repos/logrotate/logrotate/issues/81","repository_url":"https://api.github.com/repos/logrotate/logrotate","labels_url":"https://api.github.com/repos/logrotate/logrotate/issues/81/labels{/name}","comments_url":"https://api.github.com/repos/logrotate/logrotate/issues/81/comments","events_url":"https://api.github.com/repos/logrotate/logrotate/issues/81/events","html_url":"https://github.com/logrotate/logrotate/issues/81","id":184653043,"number":81,"title":"Request to have Logrotate more gracefully handle errors in its config","user":{"login":"sc-perth","id":10677739,"avatar_url":"https://avatars.githubusercontent.com/u/10677739?v=3","gravatar_id":"","url":"https://api.github.com/users/sc-perth","html_url":"https://github.com/sc-perth","followers_url":"https://api.github.com/users/sc-perth/followers","following_url":"https://api.github.com/users/sc-perth/following{/other_user}","gists_url":"https://api.github.com/users/sc-perth/gists{/gist_id}","starred_url":"https://api.github.com/users/sc-perth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sc-perth/subscriptions","organizations_url":"https://api.github.com/users/sc-perth/orgs","repos_url":"https://api.github.com/users/sc-perth/repos","events_url":"https://api.github.com/users/sc-perth/events{/privacy}","received_events_url":"https://api.github.com/users/sc-perth/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-10-22T20:44:01Z","updated_at":"2016-12-03T15:56:36Z","closed_at":null,"body":"Don't get me wrong here, this is all my fault. That said it would have been nice if logrotate had handled this situation more gracefully.\n\nLogrotate v3.10.0 will stop processing logrotate.conf directives after encountering a bad directive. This can (and did) result in large log files. I would like to request that this behavior be changed such that logrotate continues to process the remaining directives, if possible, instead of just exiting. Exit status should probably ?still? indicate an error was encountered.\n\n---\n\nMy specific hiccup: \n/etc/logrotate.conf:\n\n```\n...\ninclude /etc/logrotate.d\n...\n/var/log/pm-powersave.log {\n    ...\n}\n...\n/var/log/syslog {\n...\n}\n...\n```\n\n/etc/logrotate.d/pm-utils:\n\n```\n/var/log/pm-suspend.log /var/log/pm-powersave.log {\n...\n}\n```\n\nBecause of the above config, syslog would apparently stop processing /etc/logrotate.conf after encountering `error: /etc/logrotate.conf:131 duplicate log entry for /var/log/pm-powersave.log`. This caused /var/log/syslog and other logs to not be rotated resulting in some being well over 100MB (because it took me 2 years to notice -_-;).\n\nJudging from:\n\n<ul><li>The output of a <code>sudo logrotate -f /etc/logrotate.conf</code>:</li><ul>\n<li><code>error: /etc/logrotate.conf:131 duplicate log entry for /var/log/pm-powersave.log</code><br>\n<code>error: destination /var/log/fail2ban.log-20161022.gz already exists, skipping rotation</code><br>\n<code>error: destination /var/log/messages-20161022.gz already exists, skipping rotation</code></li>\n</ul><li>The existence of recently rotated logs</li>\n<li>The existence of un-rotated logs</li></ul>\n\nIt appears that this error in logrotate does not stop logrotate entirely, but it does stop the processing of logrotate's config file.\n"},"comment":{"url":"https://api.github.com/repos/logrotate/logrotate/issues/comments/264647226","html_url":"https://github.com/logrotate/logrotate/issues/81#issuecomment-264647226","issue_url":"https://api.github.com/repos/logrotate/logrotate/issues/81","id":264647226,"user":{"login":"sc-perth","id":10677739,"avatar_url":"https://avatars.githubusercontent.com/u/10677739?v=3","gravatar_id":"","url":"https://api.github.com/users/sc-perth","html_url":"https://github.com/sc-perth","followers_url":"https://api.github.com/users/sc-perth/followers","following_url":"https://api.github.com/users/sc-perth/following{/other_user}","gists_url":"https://api.github.com/users/sc-perth/gists{/gist_id}","starred_url":"https://api.github.com/users/sc-perth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sc-perth/subscriptions","organizations_url":"https://api.github.com/users/sc-perth/orgs","repos_url":"https://api.github.com/users/sc-perth/repos","events_url":"https://api.github.com/users/sc-perth/events{/privacy}","received_events_url":"https://api.github.com/users/sc-perth/received_events","type":"User","site_admin":false},"created_at":"2016-12-03T15:56:36Z","updated_at":"2016-12-03T15:56:36Z","body":"OK! A recent push to 3.11 in Gentoo's repository updated the noasprintf patch which unblocked my 9999 (GitHub sourced) ebuild file. I've successfully compiled & installed from HEAD. Now to recreate the situation that caused the interesting behaviour & test.\r\n\r\nThank you for your patience."}}
{"actor":{"display_login":"sc-perth"}}