Skip to content

Where are all the log files?

June 19, 2007

Todays question was:

Is there a list of all the default log files that are used in Solaris?

Not that I know of. Mostly since most software you can configure to log anywhere you wish it would be an impossible task to come up with a complete list that was of any practical benefit.

However there are some places to go looking for log files:

  1. The file /etc/syslog.conf will contain the names of logfiles written to via syslog.
  2. The contents of the directory /var/svc/log is the default location for log files from SMF. These files are connected to any daemons standard out and standard error so can grow.
  3. Then the files in /etc/default will define logfiles for services that are not using syslog. For example /var/adm/sulog

So having ticked off those log files and decided upon a strategy for maintaining them, mine is to keep 100k of log for the logs in /var/svc/log and let logadm(1M) look after them. I keep sulog forever and clean it by hand as I’m paranoid. Configuring logadm to look after the SMF logs is easy:

for i in /var/svc/log/*.log 
logadm -w $i -C1 -c -s100k

So how can I be sure that there are no more log files out there? You could use find to find all the files modified in the last 24 hours however this will get you a lot of false positives. Since what is really interesting are the active log files that are in the “/” and “/var” file systems, I can use dtrace to find them by running this script for a few hours:

/ ! (execname == "ksh" && arg0 == 63 ) &&
fds[arg0].fi_oflags & O_APPEND &&
(fds[arg0].fi_mount == "/" || fds[arg0].fi_mount == "/var" )/
      @logs[fds[arg0].fi_pathname] = count();
      logfiles[ fds[arg0].fi_pathname]++
/ logfiles[ fds[arg0].fi_pathname] == 1 &&
 ! (execname == "ksh" && arg0 == 63 ) &&
 fds[arg0].fi_oflags & O_APPEND &&
 (fds[arg0].fi_mount == "/" || fds[arg0].fi_mount == "/var" )/
     printf("%s %s", fds[arg0].fi_fs, fds[arg0].fi_pathname);

in half an hour gives me:

# dtrace -s /home/cjg/lang/d/log.d
dtrace: script '/home/cjg/lang/d/log.d' matched 2 probes
CPU     ID                    FUNCTION:NAME
 0   4575                      write:entry ufs /var/cron/log
 0   4575                      write:entry ufs /var/adm/wtmpx
 0   4575                      write:entry ufs /var/adm/sulog
 0   4575                      write:entry ufs /var/adm/messages
 0   4575                      write:entry ufs /var/apache2/logs/access_log
 0   4575                      write:entry ufs /var/svc/log/system-filesystem-autofs:default.log
 0   4575                      write:entry ufs /var/log/syslog
 0   4575                      write:entry ufs /var/log/exim/mainlog
 ^C    /var/adm/messages                                                 1
 /var/adm/sulog                                                          2
 /var/adm/wtmpx                                                          2
 /var/svc/log/system-filesystem-autofs:default.log                       4 1
 /var/apache2/logs/access_log                                            7
 /var/log/exim/mainlog                                                  28
 /var/log/syslog                                                        42
 /var/cron/log                                                         6772

Clearly there is still scope for false positives files in /var/tmp that are opened O_APPEND for example, or if you use a different shell but it gives a very good starting point.

1The autofs log file has been written to thanks to me using the well hidden feature of being able to turn automounter verbose mode on and off by accessing the f file “=v” in the as root in the root of an indirect mount point. Typically this is “/net/=v”. Equally you can set the trace level by accessing “/net/=N” where N is any integer.

2Cron is so busy as I am still running the test jobs for the timezone aware cron.


From → bsc, Solaris

One Comment
  1. Bill Palis permalink

    Chris – Any logs for IM? We rely on this tool 100% for the TASS team in Support for the Americas and it dies for no known reason. Service Desk tickets seem to cause the servers to get rebooted which sometimes help and sometimes not. If we could see the reason why IM dies when used with SunRays that would help us give those folks who support IM a chance to repair. Keep in mind we are the end users who aren’t given root access to SunRay servers.
    Thanks in advance for any help with IM.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: