There are many logs in /var/log/ For a standard home installation, which ones should I be checking regularly?


Each log serves it's own purpose. It really depends on what you're trying to check for. Some common ones are outlined below:

  • /var/log/auth.log - Information pertaining to authentication - including sudo/su activity
  • /var/log/boot.log - All information during the booting process
  • /var/log/crond.log - Information from cron daemon
  • /var/log/messages - Typical dumping point for messages not regarding the system
  • /var/log/pm-suspend.log - Logged during the Power management suspend function
  • /var/log/user.log - Information from all userlevels
  • /var/log/syslog - This organizes output from different softwares and is a "general log"
  • /var/log/kern.log - Information being logged from the kernel

There are additional logs - like the apache2 folder, mysql.log/mysql.err, and others. These are all software specific - if you don't have apache2 installed, you won't have the log files for it. The only time you would want to check logs is when an issue arises - most of the time though it'll be okay to let them sit in the dark.

  • I have three logfiles (kern,messages and syslog) totally spammed by crazy "NVRM: os_raise_smp_barrier(), invalid context!" message. So I dont check it anymore.... – Extender Oct 11 '10 at 9:14
  • egrep -v 'os_raise_smp_barrier' /var/log/{kern.log,messages,syslog} | less And, track down that message - it's symptomatic of some problem that you should fix. – waltinator Feb 22 '12 at 1:21
  • You could ask rsyslogd which files it logs to: cat /etc/rsyslog.d/* | egrep -v '^#|^$' | egrep -o '/[^ ]+' on your system. – waltinator Jun 5 '15 at 2:53

I would argue that for a standard home installation, there is no need for you to be checking any logs regularly. Though they may be helpful in diagnosing a problem or filing a bug report.

  • I concur: unless you're seriously concerned about security auditing - which is unlikely to be particularly useful for your home PC - the logs are there for figuring out what's gone wrong after something's gone wrong :) – RAOF Oct 11 '10 at 5:31

Also, you can just use the command "dmesg" to see the kernel messages (same as /var/log/kern.log) This usually tells me quickly what is (if anything) going wrong with the system


A trick that I find useful is:

touch /tmp/now  

<...make the problem happen...>  

sudo find /var/log -type f -newer /tmp/now | xargs sudo less  

That shows me every file in and under /var/log that has had something written to it since the touch /tmp/now command.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.