/var/log/messages is empty after upgrade to natty

If you disagree with the change, please feel free to discuss it on the forums and ubuntu mailing lists, but since the change was intentional, this is not a bug, so I am closing this report.

And of course, you are free to edit your rsyslog.conf to log however you like.

I don't agree that an intentionally introduced bug is not a bug.

/var/log/syslog is filled with low-level messages; /var/log/messages is a very important file and a long-standing convention. It shouldn't be removed on some developer's whim, without consultation, and without a strategy for backward compatibility or at least documenting the change.

Phillip,

I'm going to have to side with Peter Selinger here. It is absolutely unacceptable to introduce such a change without notice or warning. Other distributions do not have the problem you are attempting to justify this change with - duplicate messages - that is a problem of the default configuration in Ubuntu and not a problem with the existence of a logfile that has been THE defacto source of system messages since the beginning of time for nearly every unix admin on the planet.

To dodge the issue and push the discussion into the forums where you very well know it will die in silence is laziness and unbecoming of this distro.

Be that as it may, the place to discuss policy decisions is the development mailing list, and if you find that unsatisfactory, you can appeal to the technical board.

The arrogance in ubuntu development circles is becoming stifling

Knowing this is in vain, I also oppose this strage decision. Why does something that isn't broken have to be "fixed"?

And, btw, to help your users, instead of just killing /var/log/messages, a nicer approach would be to replace the contents of the file with something like "/var/log/messages is not supported anymore. If you need it, look here ...".

I recently upgraded one of my servers to 12.04, and I just noticed /var/log/messages is empty while doing some routine checks. My first thought was "shit, someone broke into my system, and cleaned up all trace of their activity". As someone who isn't on the technical board (just, you know, a "user"), this change appears to be completely arbitrary and unnecessary. /var/log/messages was one of the few "standard" log files that I could depend on across many Linux distributions. Making the Linux ecosystem even more fractured is not helping anyone.

I suppose we could symlink messages -> syslog to help reduce confusion.

Hi Phillip,

While I would be happy to see /var/log/messages return in some form, I would be cautious about introducing it as a symlink. What happens if someone has manually re-enabled it through /etc/rsyslog.d/50-default.conf while at the same time a new symlink points from /var/log/messages to /var/log/syslog? Would there suddenly be duplicate messages? Also, I'm not sure how logrotate would handle this. Would it archive the symlink on the next rotation, leaving no /var/log/messages behind?

On the same topic, I had a look at the relevant changelog at https://launchpad.net/ubuntu/+source/rsyslog/4.6.4-2ubuntu4. The author says this change only affects new installations, but I can tell you it's affecting LTS upgrades as well. Something to keep in mind as more people upgrade their servers from 10.04 to 12.04, and wonder where their logs went...

Trying to configure my pure-ftpd server which relies on messages, and the log window was empty. I've re-enabled it the way it should be, in rsyslogv conf. /var/log/messages is an essential part of any unix distro. What needs to happen is that the distinction between syslog and messages needs to become more contrasted they way they should be: low-level system/kernel messages to syslog, and global application notices to messages. Or, if the consensus is that they serve the same purpose, then get rid of one of them completely... no use in having the null-byte file lurking around anymore

If you remove /var/log/messages you must also update 13.500.000 Web pages that refer to it.
You just can't tell the general user to constantly scrutinize bug comments and update his rsyslog.conf.
Unless Ubuntu is only for geeks...

This bug has adversely affected the LogWatch package. Every service that specifies 'LogFile = messages' in its LogWatch .conf file (there are 40 of them) is now dead.

It looks like this bug has a few duplicates and other implications, such as to logwatch in bug 1010625. So I think the original bug should remain, since most comments here pertain to that, and it is useful to keep this bug to help track anything else that has been affected by this change.

I have created bug 1181264 to track the symlink wishlist item.

Note that I'm tentatively marking this Won't Fix for the same reason as Phillip's justification. Those annoyed by this should note that it isn't always clear that a decision to make a change will turn out to be controversial or cause disruption. This appears to be the case here. It's reasonable to make changes that aren't expected to have wider consequences or controversy as otherwise we'd get nothing done. But now that you've presented the controversy, the Ubuntu Code of Conduct clearly requires us to seek consensus.

Seeking consensus on this bug is clearly not going to be productive, as there will be obvious consensus amongst those affected by this bug (and therefore those who find the bug), and those with other use cases will be left out completely, since they won't know about the bug. So if you'd like to see this changed, then please seek consensus for a fix on the appropriate mailing lists.

I also don't see anything in the Ubuntu delta regarding this. Has this change actually been made in Debian or upstream? If so, the appropriate venue to discuss this issue may also be upstream.

Disabling /var/log/messages was a very bad move in my opinion, too.

I applied the well-know reverse patch to /etc/rsyslog.d/50-default.conf:

*.=info;*.=notice;*.=warn;
        auth,authpriv.none;
        cron,daemon.none;
        mail,news.none -/var/log/messages

(re-starting the rsyslog service therafter),
but since May 1st, 2013, that logfile remains empty :-(