Logrotate doesn't clean old system logs, allowing them to fill the disk

[Thomas A. F. Thorne]

[Impact]

Logrotate fails to rotate a log and then will continue to fail to rotate it until manual intervention takes place. If messaging has not been configured on the system there will be no warning issued to the user. The log will grow day by day until a user intervenes or the drive that the log is stored on is full.

Very large log files can make it more difficult to find useful data. Full drives make the rest of the system fail to operate. Backporting a fix would prevent drives filling up on stable releases.

[Test Case]

Go to your logs area (/var/logs) and create a file with a name ending .2, as would be created part way through the logrotate process. So if you have /var/log/syslog, /var/log/syslog.1, /var/log/syslog.2.gz, /var/log/syslog.3.gz; create a new file named /var/log/syslog.2. Your subsequent log rotate runs will fail.

[Regression Potential]

- I'd hope the potential is low as it only triggers under certain conditions that are special (target filename in the way).
- So far in those conditions it failed to rotate
- Yet If despite my hope there still manifests an issue I'd expect it could be renaming files it should not, so people would end up "missing" their logs - the good thing is that this is a rename, so they should find it at different names.
- Another thing I consider possible is that some unexpected conditions cause e.g. a crash in the changed code, in that case the logs are not rotated, but since there is no unlink the logs will still exist.
- Therefore I consider the Potential low enough to consider the fix.

[Other Info]
n/a

---

Good afternoon.
I have started seeing something very similar to Debian Dug 734688 "Logs are not rotated for a month" but in the latest Ubuntu LTS (16.04). I seem to have
$ logrotate --version
logrotate 3.8.7
bundled in it. A few weeks ago I started getting root emails such as this:
> Subject: Cron <root@warden> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
>
> /etc/cron.daily/logrotate:
> error: error creating output file /var/log/munin/munin-node.log.1: File exists
> run-parts: /etc/cron.daily/logrotate exited with return code 1
When I inspected the area of concern I was able to see that there was an existing .1 file.
manager@warden:/var/log/munin$ ll
total 580
drwxr-xr-x 2 munin adm 4096 Sep 27 06:31 ./
drwxr-xr-x 13 root syslog 4096 Oct 5 06:26 ../
-rw-r--r-- 1 root root 3440 Sep 26 13:39 munin-node-configure.log
-rw-r--r-- 1 root root 490251 Oct 5 10:25 munin-node.log
-rw-r--r-- 1 root root 56598 Sep 21 02:01 munin-node.log.1
-rw-r--r-- 1 root root 24576 Aug 31 02:01 munin-node.log.2
-rw-r--r-- 1 root root 1906 Sep 19 06:25 munin-node.log.8.gz
The contents of the munin-node.log file seem to run from the 19th September until today. Unlike other parts of this bug the .1 and .2 files do not seem to be already compressed.

I deleted all but the munin-node.log file to see if it would resolve the problem and was going to leave it at that. Then I noticed that I have had another Ubuntu machine which has been sending similar emails for the past week:
> Subject: Cron <root@trac> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
>
> /etc/cron.daily/logrotate:
> error: error creating output file /var/log/syslog.1.gz: File exists
> run-parts: /etc/cron.daily/logrotate exited with return code 1
Different file, different machine but a very similar error message.

Checking on the syslog file I can see that it better fits with other reports on this bug as my duplicated .1 files has a corresponding .1.gz file.
manager@trac:/var/log$ ll syslog*
-rw-r----- 1 syslog adm 918492 Oct 5 10:30 syslog
-rw-r----- 1 syslog adm 125819 Sep 30 06:25 syslog.1
-rw-r----- 1 syslog adm 20638 Oct 2 02:01 syslog.1.gz
-rw-r----- 1 syslog adm 41989 Sep 30 02:00 syslog.2.gz
-rw-r----- 1 syslog adm 18654 Sep 28 02:01 syslog.3.gz
-rw-r----- 1 syslog adm 31720 Sep 26 06:40 syslog.4.gz
-rw-r----- 1 syslog adm 33151 Sep 25 02:01 syslog.5.gz
-rw-r----- 1 syslog adm 17290 Sep 23 02:01 syslog.6.gz
-rw-r----- 1 syslog adm 39275 Sep 21 06:35 syslog.7.gz

There has been some speculation that a full or nearly full /var partition would cause this issue. I can confirm that /var is part of / on my systems and that presently both of them have several gigabytes of space. I run Munin an Icinga to monitor system state. Neither of these show / being completely full in the past month. They have both had /boot fill significantly. Trac had a highest use value of / being 99.28% full in the past year but warden has only had a peak of 33% in the past year.

A quick search of the internet suggests a couple of other people reporting similar issues:
https://github.com/gitlabhq/gitlabhq/issues/6894
http://raspberrypi.stackexchange.com/questions/22545/why-are-system-logs-not-rotating

I do not believe that I have altered by logrotate configuration files but here is a copy of the ones I know about:
$ cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
    missingok
    monthly
    create 0664 root utmp
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0660 root utmp
    rotate 1
}

# system-specific logs may be configured here

$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
{
            rotate 7
            daily
            missingok
            notifempty
            delaycompress
            compress
            postrotate
                        reload rsyslog >/dev/null 2>&1 || true
            endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
            rotate 4
            weekly
            missingok
            notifempty
            compress
            delaycompress
            sharedscripts
            postrotate
                        reload rsyslog >/dev/null 2>&1 || true
            endscript
}

manager@trac:/var/log$ cat /etc/logrotate.d/munin-node
/var/log/munin/munin-node.log {
            daily
            missingok
            rotate 7
            compress
            copytruncate
            notifempty
            create 640 root root
}

I am confident that is all the files which are relative to the configuration:
manager@trac:/var/log$ rgrep syslog /etc/logrotate.*
/etc/logrotate.conf:# use the syslog group by default, since this is the owning group
/etc/logrotate.conf:# of /var/log/syslog.
/etc/logrotate.conf:su root syslog
/etc/logrotate.d/ufw: invoke-rc.d rsyslog reload >/dev/null 2>&1 || true
/etc/logrotate.d/rsyslog:/var/log/syslog
/etc/logrotate.d/rsyslog: reload rsyslog >/dev/null 2>&1 || true
/etc/logrotate.d/rsyslog: reload rsyslog >/dev/null 2>&1 || true
manager@trac:/var/log$ rgrep munin /etc/logrotate.*
/etc/logrotate.d/munin-node:/var/log/munin/munin-node.log

If there is anything else I can do to help diagnose the issue please let me know.

Usual boiler plate bits:
"trac" machine:
$ lsb_release -rd
Description: Ubuntu 14.04.5 LTS
Release: 14.04

$ apt-cache policy logrotate
logrotate:
  Installed: 3.8.7-1ubuntu1
  Candidate: 3.8.7-1ubuntu1
  Version table:
 *** 3.8.7-1ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

"warden" machine:
$ lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

$ apt-cache policy logrotate
logrotate:
  Installed: 3.8.7-2ubuntu2
  Candidate: 3.8.7-2ubuntu2
  Version table:
 *** 3.8.7-2ubuntu2 500
        500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
N: Ignoring file '50unattended-upgrades.ucf-dist' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: logrotate 3.8.7-1ubuntu1
ProcVersionSignature: Ubuntu 4.2.0-42.49~14.04.1-generic 4.2.8-ckt12
Uname: Linux 4.2.0-42-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.21
Architecture: amd64
Date: Wed Oct 5 11:14:53 2016
InstallationDate: Installed on 2015-12-14 (295 days ago)
InstallationMedia: Ubuntu-Server 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805)
SourcePackage: logrotate
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mikkel Kirkgaard Nielsen (mikini)]

I am also seing this on a 14.04 server using logrotate package version 3.8.7-1ubuntu1:

$ dpkg -l|grep logrotate
ii logrotate 3.8.7-1ubuntu1 amd64 Log rotation utility

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

Execution of logrotate from cron.daily aborts because of an existing file. Mail from cron below ("Filen eksisterer" is Danish for "File exists"):

/etc/cron.daily/logrotate:
error: error creating output file /var/log/syslog.1.gz: Filen eksisterer
run-parts: /etc/cron.daily/logrotate exited with return code 1

Looking at the syslog files there is both a syslog.1 and a syslog.1.gz where the latter shouldn't exist because of delaycompress option. Also the .gz is a compressed version of the plain file:

$ gunzip --stdout /var/log/syslog.1.gz | diff --report-identical-files - /var/log/syslog.1
Files - and /var/log/syslog.1 are identical

This suggests that logrotate was most likely interrupted after compressing syslog.1 to syslog.1.gz but before it was moved/rotated into syslog.2.gz. On subsequent executions this stale file causes logrotate to abort rotation entirely.

The issue has been addressed in recent upstream releases; https://github.com/logrotate/logrotate/pull/23

Also discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734688

[Thomas A. F. Thorne (tafthorne)]

Still present on 14.04.1. I am seeing this again today.

I wonder if this would count as a papercut? I am not really sure as https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission says "Have the impression the desktop is rock solid." and this is a log rotation system that only moans if root mail is setup. On the other hand https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Triage/Classify%20as%20a%20papercut?highlight=%28CategoryPapercuts%29 says "If a bug is trivial to fix, you shall classify it as a papercut by marking it as affecting the "hundredpapercuts" project." and this bug just needs the upstream bug brought in. It would make at least 6 of us feel like someone is caring too.

Front page of the One Hundred Papercuts says "If any doubt, you can ask any time." so I shall add papercuts-ninja list to the subscription. This is a very low traffic bug so someone can unsubscribe them before this thread generates more than a couple of posts.

[Christian Ehrhardt  (paelzer)]

Hi,
the fix is upstream released in logwatch 3.11 but we are post freeze for zesty.
We will almost for sure pick that up in zesty+1.

The question now is for the SRU work to at least Trusty and Xenial.
The upstream fix [1] is not super-small and I haven't checked yet how cleanly that would apply to the older versions isolated from the overall version bump.

As I said, I haven't tried yet, but it might be more than a papercut.
One good thing is that this is just the right time still - as there started a new event for issues just like that [2].
There the - bigger cuts - can be discussed and people from the community willing to help will be guided by experienced developers.
I'm subscribing myself here for now, but it would be a pleasure to look into that together next Wednesday.

[1]: https://github.com/logrotate/logrotate/commit/fc1c3eff61edf8e9f0a4bfa980f3a6030a6b271f
[2]: https://lists.ubuntu.com/archives/ubuntu-server/2017-March/007502.html

[Jon Ribbens (jribbens-r)]

I'll just point out that this can perhaps be considered a security bug, because if log rotations stop happening, the disk will inevitably fill up sooner or later, which means security patches will stop being applied, which means the machine will become insecure. You might say that that is a bit tenuous, but it is the actual real effect and a genuine problem I have been having with Ubuntu servers.

[Thomas A. F. Thorne (tafthorne)]

That does sound a bit tenuous but could be easily settled by a policy decision on whether:
 i) Bugs that directly block the installation of security patches are security bugs.
 ii) Bugs that cause disk space to fill which in turn block security patch install are security bugs.

I would have said that i sounds like a possible valid case but ii is getting a bit drawn out. Still I expect the situation and suggestion will have popped up before somewhere. Looking at https://wiki.ubuntu.com/DebuggingSecurity#How%20to%20File it does not mention blocking security patches as a criteria which would thrown the whole idea of it being a security bug out.

If in doubt ask. I shall try heading over to IRC and seeing if someone can answer the question.

[Thomas A. F. Thorne (tafthorne)]

I checked on IRC #ubuntu-hardened (the actual name for the #ubuntu-security channel) and was told that "we typically only consider bugs to have a security impact if there's an attacker to the story". The reason for that is "else, almost every bug has an indirect security impact" which I can see the logic to.

So that means this is not a security bug, just a bug.

[Thomas A. F. Thorne (tafthorne)]

The stock not security reply can be found at https://wiki.ubuntu.com/SecurityTeam/BugTriage#Not_Security which says "unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy."

[Alberto Salvia Novella (es20490446e)]

Thomas A. F. Thorne:
 > "If a bug is trivial to fix, you shall classify it as a papercut by
 > marking it as affecting the "hundredpapercuts" project." and this bug
 > just needs the upstream bug brought in.

Christian Ehrhardt:
 > As I said, I haven't tried yet, but it might be more than a papercut.

It looks like a papercut. Most of the patch just adds new checks, so
it's likely to fit any version of the package:

(https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=734688;filename=logrotate-dest-file-exists.patch;msg=20)

So I'll mark it as such now.

Thomas A. F. Thorne:
 > This is a very low traffic bug so someone can unsubscribe them before
 > this thread generates more than a couple of posts.

I'll unsubscribe the Papercuts Ninjas team from the bug now, but feel
free to still reply messages to the mailing list if that fits.

Thank you 🖒

[Christian Ehrhardt  (paelzer)]

Things are a bit more complex as it also changes a build time self test.
These Tests are running, see https://launchpadlibrarian.net/228546427/buildlog_ubuntu-xenial-s390x.logrotate_3.8.7-2ubuntu2_BUILDING.txt.gz
The changes to the tests add new tests for these cases, so I think we want that.

And then there is a direct follow up fix for the fix which has to be considered as well.
https://github.com/logrotate/logrotate/commit/aff4a30807218a52b6b5f200c5aa0eea335547ba

OTOH T-Z are on almost the same version, so once done that should apply.
Working on the backports for the SRU now.

[Christian Ehrhardt  (paelzer)]

The backports were as smooth as expected.
I'm happy they added a test for the case upstream (and all the others that are there already).
That gives me some confidence in the changes.

I'll do some regression testing on my end and when all is complete we can start bringing it to zesty and from there consider SRUs.

@tafthorne
- Since you know the setup to trigger this particular issue I wanted to ask you if you could try the following ppa's and report back here. For Xenial, Yakkety and Zesty please use [1], and for Trusty [2].
- Also you could help me adding a proper SRU Template here, copy from [3] and modify the adapted version here in the top into the description.

I can help you if needed, please catch me on IRC in that case.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2623
[2]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2624/+packages
[3]: https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

[Christian Ehrhardt  (paelzer)]

The second link is better as "https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2624/" withut the tail +packages. (you get from one to the other on that page, so the initial link is not too bad)

[Thomas A. F. Thorne (tafthorne)]

SRU Bug Template

[Impact]

Logrotate fails to rotate a log and then will continue to fail to rotate it until manual intervention takes place. If messaging has not been configured on the system there will be no warning issued to the user. The log will grow day by day until a user intervenes or the drive that the log is stored on is full.

Very large log files can make it more difficult to find useful data. Full drives make the rest of the system fail to operate. Backporting a fix would prevent drives filling up on stable releases.

[Test Case]

Go to your logs area (/var/logs) and create a file with a name ending .2, as would be created part way through the logrotate process. So if you have /var/log/syslog, /var/log/syslog.1, /var/log/syslog.2.gz, /var/log/syslog.3.gz; create a new file named /var/log/syslog.2. Your subsequent log rotate runs will fail.

[Regression Potential]

<I have not looked into the changes yet>

[Other Info]

[Christian Ehrhardt  (paelzer)]

Moving the template up and adding more to the regression statement.
Thanks a lot for the testcase!

[Thomas A. F. Thorne (tafthorne)]

Installing for 16.04 xenial on a machine that has just reproduced the issue on its own. If I do not see the error message emailed out to me tonight then it is likely that the fix has succeeded. I shall try to post an update promptly, sorry for the delay.

[Thomas A. F. Thorne (tafthorne)]

The proposed change added under https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2623 seems to have resolved my issue.

Before the change I received an email stating:
/etc/cron.daily/logrotate:
error: error creating output file /var/log/apt-cacher-ng/apt-cacher.err.1.gz: File exists
error: error creating output file /var/log/auth.log.1.gz: File exists
run-parts: /etc/cron.daily/logrotate exited with return code 1

After applying the change I have received an email stating:
/etc/cron.daily/logrotate:
error: destination /var/log/apt-cacher-ng/apt-cacher.err.1.gz already exists, renaming to /var/log/apt-cacher-ng/apt-cacher.err.1.gz-2017040406.backup

I can also see what looks like a normal pattern of file names a modification dates:
$ ls -l /var/log/apt-cacher-ng/
total 25772
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 0 Apr 4 06:26 apt-cacher.err
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 297 Mar 31 13:40 apt-cacher.err.1
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 0 Mar 31 06:26 apt-cacher.err.1.gz-2017040406.backup
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 29 06:25 apt-cacher.err.2.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 190 Mar 29 01:53 apt-cacher.err.3.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 27 06:25 apt-cacher.err.4.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 26 06:25 apt-cacher.err.5.gz
...

Hopefully I will receive no email overnight tonight and log rotations will proceed as intended.

[Christian Ehrhardt  (paelzer)]

Thank you Thomas, the new mail content you referred to is already the fix in place and working.
Thank you so much for double checking with me on these PPAs.

So we have all in place:
- SRU Template
- Patches reviewed and prepared
- Confidence in the fix by pre-testing ppas

With that they are ready to be pushed those into the SRU process, which means they will get to the "unapproved" queue of the releases.

The SRU Team will double check there if I had made any errors or if we both overlooked something. I hope that does not appear like a burden, the purpose of this process is to mimimize the risk to unintentionally regress users.

But before that the next burden is that I can't upload logrotate on my own yet, so I have to subscribe ubuntu-sponsors to help us doing so.
@Sponsors since this is tested via bileto tickets a publish on the two tickets might be the easiest way.
https://bileto.ubuntu.com/#/ticket/2623
https://bileto.ubuntu.com/#/ticket/2624

[Thomas A. F. Thorne (tafthorne)]

To finish off my confirmation of the fix, I did not see any email notifications overnight. When I look at the relevant log files I can see the rotation is progressing:

$ ls -l /var/log/apt-cacher-ng/apt-cacher.err*
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 0 Apr 5 06:28 /var/log/apt-cacher-ng/apt-cacher.err
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 0 Apr 4 06:26 /var/log/apt-cacher-ng/apt-cacher.err.1
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 0 Mar 31 06:26 /var/log/apt-cacher-ng/apt-cacher.err.1.gz-2017040406.backup
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 180 Mar 31 13:40 /var/log/apt-cacher-ng/apt-cacher.err.2.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 29 06:25 /var/log/apt-cacher-ng/apt-cacher.err.3.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 190 Mar 29 01:53 /var/log/apt-cacher-ng/apt-cacher.err.4.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 27 06:25 /var/log/apt-cacher-ng/apt-cacher.err.5.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 26 06:25 /var/log/apt-cacher-ng/apt-cacher.err.6.gz
-rw-r--r-- 1 apt-cacher-ng apt-cacher-ng 20 Mar 25 06:25 /var/log/apt-cacher-ng/apt-cacher.err.7.gz

> Thank you Thomas

You are welcome. Thank you for fixing the bug (or porting the fix into Ubuntu).

> I hope that does not appear like a burden, the purpose of this process is to mimimize the risk to unintentionally regress users.

That is fine. I work in software development so I know the benefits of thorough QA.

[Christian Ehrhardt  (paelzer)]

X/Y/Z uploads are published.
Due to the Freeze on the Zesty they are on unapproved queue there as well now.

Once it migrated into Zesty-Release the SRU Team will start to consider it for the older releases.

[Launchpad Janitor (janitor)]

This bug was fixed in the package logrotate - 3.8.7-2ubuntu3

---------------
logrotate (3.8.7-2ubuntu3) zesty; urgency=medium

  * createOutputFile: rename already existing file (LP: #1630516)
    - d/p/ubuntu/createOutputFile-eliminate-stat-open-TOCTOU-race.patch
    - d/p/ubuntu/createOutputFile-rename-already-existing-file.patch

 -- Christian Ehrhardt <email address hidden> Wed, 22 Mar 2017 11:47:34 +0100

[Steve Langasek (vorlon)]

Hello Thomas, or anyone else affected,

Accepted logrotate into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/logrotate/3.8.7-2ubuntu2.16.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Steve Langasek (vorlon)]

Hello Thomas, or anyone else affected,

Accepted logrotate into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/logrotate/3.8.7-2ubuntu2.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Steve Langasek (vorlon)]

Hello Thomas, or anyone else affected,

Accepted logrotate into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/logrotate/3.8.7-1ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Thomas A. F. Thorne (tafthorne)]

Running through on Xenial.

$ sudo apt-get install logrotate/xenial-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '3.8.7-2ubuntu2.16.04.1' (Ubuntu:16.04/xenial-proposed [amd64]) for 'logrotate'
The following packages will be upgraded:
  logrotate
1 to upgrade, 0 to newly install, 0 to remove and 22 not to upgrade.
Need to get 37.8 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 logrotate amd64 3.8.7-2ubuntu2.16.04.1 [37.8 kB]
Fetched 37.8 kB in 0s (639 kB/s)
(Reading database ... 889765 files and directories currently installed.)
Preparing to unpack .../logrotate_3.8.7-2ubuntu2.16.04.1_amd64.deb ...
Unpacking logrotate (3.8.7-2ubuntu2.16.04.1) over (3.8.7-2ubuntu2) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up logrotate (3.8.7-2ubuntu2.16.04.1) ...
$ cd /var/log/
$ sudo touch syslog.2
$ ls -l syslog*
-rw-r----- 1 syslog adm 193861 Apr 25 15:48 syslog
-rw-r----- 1 syslog adm 586698 Apr 25 07:35 syslog.1
-rw-r--r-- 1 root root 0 Apr 25 15:48 syslog.2
-rw-r----- 1 syslog adm 26955 Apr 24 07:35 syslog.2.gz
-rw-r----- 1 syslog adm 26695 Apr 23 07:35 syslog.3.gz
-rw-r----- 1 syslog adm 31307 Apr 22 07:35 syslog.4.gz
-rw-r----- 1 syslog adm 32909 Apr 21 07:35 syslog.5.gz
-rw-r----- 1 syslog adm 39182 Apr 20 07:35 syslog.6.gz
-rw-r----- 1 syslog adm 27036 Apr 19 07:35 syslog.7.gz
Either things will fail overnight (well first thing tomorrow morning or all will be well. I shall get back in touch soon.

[Thomas A. F. Thorne (tafthorne)]

Looks to me like everything worked fine overnight.
$ ls -l /var/log/syslog*
-rw-r----- 1 syslog adm 587351 Apr 26 12:10 /var/log/syslog
-rw-r----- 1 syslog adm 1824727 Apr 26 07:38 /var/log/syslog.1
-rw-r--r-- 1 root root 0 Apr 25 15:48 /var/log/syslog.2
-rw-r----- 1 syslog adm 37783 Apr 25 07:35 /var/log/syslog.2.gz
-rw-r----- 1 syslog adm 26955 Apr 24 07:35 /var/log/syslog.3.gz
-rw-r----- 1 syslog adm 26695 Apr 23 07:35 /var/log/syslog.4.gz
-rw-r----- 1 syslog adm 31307 Apr 22 07:35 /var/log/syslog.5.gz
-rw-r----- 1 syslog adm 32909 Apr 21 07:35 /var/log/syslog.6.gz
-rw-r----- 1 syslog adm 39182 Apr 20 07:35 /var/log/syslog.7.gz

The presence of the inconveniently named file looks to have been ignored and the log rotations continued unabated.

> change the tag from verification-needed to verification-done

I have only verified this on Xenia so far. I think that means I leave the tags alone for now right?

[Christian Ehrhardt  (paelzer)]

Hi Thomas,
thanks for your ongoing work.
Look at [1] - in this case you'd add verification-done-xenial now.
Once all needed tags are added (+Trusty, +Yakkety) you'd also remove the verification-needed.

[1]: https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#Updating_the_bug_report

[Thomas A. F. Thorne (tafthorne)]

Hi Christian,
A more careful read through of the instructions you link to and I have spotted the required tag. Now added that as requested. I'll try to get the other two tested using lsc tomorrow.
Tag now added.

[Launchpad Janitor (janitor)]

This bug was fixed in the package logrotate - 3.8.7-2ubuntu2.16.04.1

---------------
logrotate (3.8.7-2ubuntu2.16.04.1) xenial; urgency=medium

  * createOutputFile: rename already existing file (LP: #1630516)
    - d/p/ubuntu/createOutputFile-eliminate-stat-open-TOCTOU-race.patch
    - d/p/ubuntu/createOutputFile-rename-already-existing-file.patch

 -- Christian Ehrhardt <email address hidden> Wed, 22 Mar 2017 11:47:34 +0100

[Chris J Arges (arges)]

I have validated the trusty version works as expected! Thanks

[Chris J Arges (arges)]

Also validated on Yakkety.

[Launchpad Janitor (janitor)]

This bug was fixed in the package logrotate - 3.8.7-1ubuntu1.1

---------------
logrotate (3.8.7-1ubuntu1.1) trusty; urgency=medium

  * createOutputFile: rename already existing file (LP: #1630516)
    - d/p/ubuntu/createOutputFile-eliminate-stat-open-TOCTOU-race.patch
    - d/p/ubuntu/createOutputFile-rename-already-existing-file.patch

 -- Christian Ehrhardt <email address hidden> Wed, 22 Mar 2017 12:43:10 +0100

[Chris J Arges (arges)]

The verification of the Stable Release Update for logrotate has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package logrotate - 3.8.7-2ubuntu2.16.10.1

---------------
logrotate (3.8.7-2ubuntu2.16.10.1) yakkety; urgency=medium

  * createOutputFile: rename already existing file (LP: #1630516)
    - d/p/ubuntu/createOutputFile-eliminate-stat-open-TOCTOU-race.patch
    - d/p/ubuntu/createOutputFile-rename-already-existing-file.patch

 -- Christian Ehrhardt <email address hidden> Wed, 22 Mar 2017 11:47:34 +0100