logrotate cron spams when only apache2.2-common installed

How did you manage to have the packaget manager remove /var/log/apache2 without touching /etc/logrotate.d/apache2? The only way I've managed to get apt to remove /var/log/apache2 is by purging apache2.2-common, and that also removes /etc/logrotate.d/apache2.

Was it a fresh install of Hardy, or was it an upgrade from a previous Ubuntu version? Do you remember which Apache2 packets you had installed; what MPM?

Andreas Olsson wrote:
> How did you manage to have the packaget manager remove /var/log/apache2
> without touching /etc/logrotate.d/apache2? The only way I've managed to
> get apt to remove /var/log/apache2 is by purging apache2.2-common, and
> that also removes /etc/logrotate.d/apache2.
>
> Was it a fresh install of Hardy, or was it an upgrade from a previous
> Ubuntu version? Do you remember which Apache2 packets you had installed;
> what MPM?
>
It's not a fresh install. It was updated from dapper. Here's my guess at
what happened. You can tell me if it makes sense.

I installed libapache2-something-dev at some point on that machine to
compile an apache module (which was to be installed on other machines).
That -dev package pulled in the apache2-common package. No apache server
was every installed on that machine. Some time later, I remove (not
purge) these packages. When the -common package is being removed, the
/var/log/apache2 directory goes away without problems since there are no
files in it (because no apache web server ever run on that machine), but
the /etc/logrotate.d/apache2 stays (because it is a conffile).

I *think* that's how it happened, but I think the bug should still be
fixed irrespective of that. It's the right thing to do for conffiles
that are executed (logrotate stuff, init.d stuff, crontab entries, etc.)
to check that their package hasn't been removed before doing their thing.

Thanks,

  Christian

Which of these events took place when you ran Dapper and what was done after the upgrade to Hardy?

Andreas Olsson wrote:
> Which of these events took place when you ran Dapper and what was done
> after the upgrade to Hardy?
>
Probably the install (and use to compile stuff) was done on dapper and
the removal on hardy. But as far as I see, it's still possible to get
the same problem on hardy only. If only by installing apache2.2-common
and afterwards removing it... Which, granted, would be a bit pointless,
bit still, packages that have been removed but not purged should never
be able to generate emails to root every day, no?

  Christian

I'll see if I can recreate the scenario going back to dapper.

Regarding getting the same problem on Hardy by simpling installing and removing apache2.2-common; have you actually tried it? I have, and I wrote about it in my first comment.

Well, I guess there still might be the possibility of lograte rotating away the existing logs, and leaving /var/log/apache2 empty. I don't think so, but I guess I could take a closer look at exactly what the apache2 logrotate does.

Andreas Olsson wrote:
> I'll see if I can recreate the scenario going back to dapper.
>
> Regarding getting the same problem on Hardy by simpling installing and
> removing apache2.2-common; have you actually tried it? I have, and I
> wrote about it in my first comment.
>
> Well, I guess there still might be the possibility of lograte rotating
> away the existing logs, and leaving /var/log/apache2 empty. I don't
> think so, but I guess I could take a closer look at exactly what the
> apache2 logrotate does.
>
Okay, I hadn't tried that one, and you're right that it won't reproduce
this bug report. The reason is that the postinst touches
/var/log/apache2/{error,access}.log on a new install. Presumably this
bug would come from having installed an apache2-common which didn't have
these lines in its postinst.

But in general, it just seems cleaner to me to have the logrotate.d file
do a check similar to the check for the existence of the apache2
executable at the beginning of /etc/init.d/apache2. And it also behaves
better on upgrade from a previous version which didn't have that check,
at least compared to the touch /var/log/foo. But if course, it's not
entirely possible that I'm missing something too.

This bug is hardly critical of course, but I thought I'd file it
nonetheless in the spirit of improving the quality of Ubuntu. Thanks for
having a look at this! (Although the quick response may encourage me to
file more bug reports in the future when I see bugs. :-) )

  Christian

Seems as if the Dapper apache2-common does create/touch the files /var/log/apache2/{error,access}.log.

I've also taken a closer look at the apache2 logrotate. Can't make it to do away with {error,access}.log, which I guess makes sense considering the notifempty option.

Not sure if there is anything else I can do unless you help me by showing how to recreate the problem.

Nevertheless, thanks for taking the time to report a potential bug.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!