[SOLVED]DRM errors fill up /var/log

SoleSoul · 2009-09-08 15:51:49

Greeitngs
I found out a hour ago that my HD is full.
After some time I found the problem: /var/log weighs 4.5GB... It's ridiculous
I searched the wiki, here in the forum and google and I found two things (I think):
1) the normal way to deal with logs cleanup is logrotate <- this is weird because there is no wiki page about it.
2) when /var/log is that big it means there is a big problem somewhere...

Now I need help in both fields.

The most common line I can not miss because it's everywhere is:
Sep 6 00:02:01 *hostname* kernel: [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22

Can someone help me please? I'm a bit lost...
Thanks

The results of googling... :
(http://linux.derkeiler.com/Mailing-List … 11735.html)
(http://linux.derkeiler.com/Mailing-List … 11230.html)

Last edited by SoleSoul (2009-09-09 11:39:54)

DonVla · 2009-09-08 16:40:00

Which log files/directories got so big? ("du -s /var/log/*")
These files are only text files, so the problem must be elsewhere.
Read man logrotate.
Simple /etc/logrotate.conf file:

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 52

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

# uncomment this if you want your log files compressed
compress

# Logs are moved into directory for rotation
olddir /var/log/archive

# Ignore pacman saved files
tabooext + .pacorig .pacnew .pacsave

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

then add logrotate to cron.daily. i think it's there by default.

ps: D'oh! I haven't read yr post to the end
i have no clue about the drm problem.

Last edited by DonVla (2009-09-08 16:42:01)

SoleSoul · 2009-09-08 16:43:05

I know these are text file but take a look at that:
539.5MB everything.log.1
539.3MB kernel.log.1
538.0MB errors.log.1
467.7MB everything.log
467.6MB kernel.log
467.0MB errors.log
257.5MB everything.log.2
257.4MB kernel.log.2
256.1MB errors.log.2
136.4MB kernel.log.3
136.4MB everything.log.3
136.0MB errors.log.3
54.8MB everything.log.4
54.8MB kernel.log.4
54.6MB errors.log.4

DonVla · 2009-09-08 16:50:15

Afais logrotate works, but does not gzip the logfiles.
Add/uncomment "compress" to/in your logrotate.conf file.
A _very_ dirty walkaround would be to add a filter to syslog-ng.conf. Smth like

filter f_* {not message("[drm:drm_wait_vblank]"); };

SoleSoul · 2009-09-08 18:47:06

I think there is a misunderstanding.
Thank you for the explanation but before I ask how to use logrotate I want to be sure that I really have to.
As I understand I shouldn't touch it because it works automatically, you, for example, doesn't touch it, am I wrong?

So the problem has to be somewhere else.
The question is whether what I think is true and I shouldn't touch logrotate?
And if the problem is elsewhere, what can I do?

Thanks.

DonVla · 2009-09-08 22:10:16

Hello SoleSoul,

logrotate seems to work.
Your problem is a problem with drm. The error massage obviously fills up your logfiles.
A simple google search gave me this: https://bugzilla.redhat.com/show_bug.cgi?id=494838
Are you using compiz or a 3d accelerated desktop, eg xcompmgr or the built-in kde one?
If yes, in the link above there are some solutions.
However, it is sane to add the compress option to the logrotate.conf file as described above.
For now you can simply delete the logfiles, if you don't need them.
Hope this helps,
Vlad

SoleSoul · 2009-09-09 09:18:32

This sure helps!
(I'm using stand alone compiz session)
The bug report you linked to gave me two possible ways to stop the messages. I chose to disable the "sync to vblank" option in compiz and that's all.
(the other way was to set compiz to --indirect-rendering which I think is unnecessarily drastic)

Now about the logs.
Which files in the directory /var/log/ are safe to delete? Can I delete all the files which has .log in their name?
And if I won't delete them, would they be cleaned up automatically?

I'll see how this compression works.

Thank you!

DonVla · 2009-09-09 09:27:28

Glad to see that the drm issue is solved.
You have only to uncomment the compress option in logrotate.conf

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

and set

# keep <X> weeks worth of backlogs
rotate <X>

<X> to the number of weeks you want to keep the logs. Logrotate deletes automatically the logs older then <X> weeks.
The logfiles are only interesting for admins and people who actually read them .
So if you don't, then you can delete them.

SoleSoul · 2009-09-09 10:24:59

Thank you very much for your time and kind help.
Problem solved!

DonVla · 2009-09-09 11:32:05

SoleSoul,
I would change the topic to "problem with drm" or similar.
It was actually a drm and not a logrotate problem.

SoleSoul · 2009-09-09 11:40:22

Done

vacant · 2009-09-09 11:56:57

You can also stop your disk filling by not logging those errors.

Read this thread which stops similar errors.

DonVla · 2009-09-09 19:16:28

@vacant
It's a _very_ dirty workaround.
This undermines the sense of logfiles. These files are there to record the system's activities including errors.
So disabling the logging through error filters makes these files totally senseless.

vacant · 2009-09-09 21:19:05

DonVla wrote:

So disabling the logging through error filters makes these files totally senseless.

Actually, by filtering out tens of thousands of duplicate messages the log files are now better suited for their purpose - reporting real problems. So three months after installing the filter I'm using the "senseless" log files in exactly the same way as I always have done.

Once I've been alerted to a problem by reading the log file and (a) I know it's just a warning (b) I know it is ongoing, then I do not need tens of thousands of reminders. In fact as root "administrator", I've taken responsibility and I don't need any log entries until I decide to reinstate the logging ability (e.g. see what happens after a kernel or fglrx update).

vacant · 2009-10-12 08:04:59

A check on my system reveals that logs files appear to be no longer filling with duplicate "fglrx" messages, so I've tentatively removed the filters I implemented. Kernel update cleared it? Catalyst update fixed it? I don't know.

SoleSoul · 2009-10-12 10:03:50

I disabled vsync in compiz so I don't get these messages.
I'll re-enable it and see if the problem is really solved.

edit: I can confirm. I re-enabled "sync to vblank" in compiz and the error is no more.

Last edited by SoleSoul (2009-10-15 09:46:15)

Arch Linux

#1 2009-09-08 15:51:49

[SOLVED]DRM errors fill up /var/log

#2 2009-09-08 16:40:00

Re: [SOLVED]DRM errors fill up /var/log

#3 2009-09-08 16:43:05

Re: [SOLVED]DRM errors fill up /var/log

#4 2009-09-08 16:50:15

Re: [SOLVED]DRM errors fill up /var/log

#5 2009-09-08 18:47:06

Re: [SOLVED]DRM errors fill up /var/log

#6 2009-09-08 22:10:16

Re: [SOLVED]DRM errors fill up /var/log

#7 2009-09-09 09:18:32

Re: [SOLVED]DRM errors fill up /var/log

#8 2009-09-09 09:27:28

Re: [SOLVED]DRM errors fill up /var/log

#9 2009-09-09 10:24:59

Re: [SOLVED]DRM errors fill up /var/log

#10 2009-09-09 11:32:05

Re: [SOLVED]DRM errors fill up /var/log

#11 2009-09-09 11:40:22

Re: [SOLVED]DRM errors fill up /var/log

#12 2009-09-09 11:56:57

Re: [SOLVED]DRM errors fill up /var/log

#13 2009-09-09 19:16:28

Re: [SOLVED]DRM errors fill up /var/log

#14 2009-09-09 21:19:05

Re: [SOLVED]DRM errors fill up /var/log

#15 2009-10-12 08:04:59

Re: [SOLVED]DRM errors fill up /var/log

#16 2009-10-12 10:03:50

Re: [SOLVED]DRM errors fill up /var/log

Board footer