How To Fix Analog Error: “Warning F: Failed to open logfile”
We use analog at work to perform analysis of our Apache server logs. I was setting up a new server recently and after installing and configuring analog I found I was getting an error every time I tried to run analog against our logfiles. The error was as follows:
1 | Warning F: Failed to open logfile /var/log/httpd/access_log: ignoring it |
If you are having a similar problem, hopefully this post will help you solve it.
There are a couple of basic causes of this error. The first and most obvious is that analog genuinely can’t open the logfile(s) in question because it either doesn’t exist at the location specified, or else it exists but cannot be opened by analog due to insufficient permissions. The second is that the logfile in question is too large to be processed (exactly what constitutes “too large” varies, but it typically means greater than either 2GiB or 4GiB on a 32bit system).
File doesn’t exist, or has insufficient permissions
This situation is easy to test for. First ensure you are logged in as the user who runs analog when it gives the error (if you run it manually you are fine, but if you run it via another user’s crontab for example you need to log in as that user to test). Next enter the following command (assuming analog is failing to open /var/log/httpd/access_log):
1 | head /var/log/httpd/access_log |
If you get the first few lines of your logfile printed to the terminal, then you don’t have a permissions error. Skip to the next section.
If you get an error indicating that the file could not be found, then you need to adjust the LOGFILE line(s) in your analog.cfg (typically located in /etc/analog.cfg) to point to the real location of your logfile(s).
If you get an error indicating that you have insufficient permissions, you will either need to run analog as a user who does have the correct permissions, or else alter the permissions of the logfile so that you can execute the command successfully. Remember that although the file itself may have adequate permissions, the entire path to the file also needs to have adequate permissions. On my CentOS system for example, the logfile at /var/log/httpd/access_log is readable by everyone, but the /var/log/httpd directory is only readable by root, which means that running analog on this logfile as any user other than root would fail.
If you need to alter permissions, it is only necessary to make the file readable, so the following is sufficient:
1 | sudo chmod a+r /var/log/httpd/access_log |
Again be sure to repeat this for any parent directories of your logfile which are unreadable.
Log files are too large
This is the issue I had, and it caused me half an hour or so of frustration trying to find the problem! Luckily it is simple enough to fix. The cause of this issue is that the logfiles are not rotated frequently enough and grow too large. In my case, httpd logs were set to rotate at the default 1 week. This is fine for most sites, but it happens that the site I am working on is fairly busy, and a week’s worth of access logs amount to almost 5GiB. To adjust the log rotation settings, I use logrotate, which is configured via files placed in /etc/logrotate.d on my system. The file which needs editing in this case is /etc/logrotate.d/httpd. I won’t go into the details of logrotate settings here, but I will give an example of my configuration. I set it to rotate logs daily, and keep 28 days worth of historical logs:
1 2 3 4 5 6 7 8 9 10 11 | cat /etc/logrotate.d/httpd /var/log/httpd/*log { missingok notifempty sharedscripts postrotate /sbin/service httpd reload > /dev/null 2>/dev/null || true endscript daily rotate 28 } |
All future logfiles should now be well under the OS file size limit. However if you have existing logfiles which you would like analog to be able to process but are too big, you can split them down into smaller files. To do this, use wc to find the number of lines in your file (I’m using a file named access_log.1 in this example):
1 | wc -l access_log.1 |
That should give you something like:
1 | 16542827 access_log.1 |
Next you need to decide into how many chunks you would like to split the file. My file is almost 5GiB, so I’m going to split it into 5 chunks. Take the number of lines returned by wc and divide it by the number of chunks (it doesn’t have to be exact). This gives me roughly 3300000 lines per file, so that’s the figure I’ll use for splitting:
1 | split -l 3300000 access_log.1 |
This may take a while for large files, but once it’s done you should now find that you have some new files along with your old access logs:
1 2 3 4 5 6 7 8 9 10 11 12 | ls -l total 13411008 -rw-r--r-- 1 root root 16345797 Sep 16 11:29 access_log -rw-r--r-- 1 root root 4582662485 Sep 16 11:05 access_log.1 -rw-r--r-- 1 root root 4488483066 Sep 12 04:11 access_log.2 -rw-r--r-- 1 root root 49594 Sep 16 11:28 error_log -rw-r--r-- 1 root root 918092183 Sep 16 11:27 xaa -rw-r--r-- 1 root root 911760823 Sep 16 11:27 xab -rw-r--r-- 1 root root 912206727 Sep 16 11:28 xac -rw-r--r-- 1 root root 912078937 Sep 16 11:28 xad -rw-r--r-- 1 root root 917153546 Sep 16 11:29 xae -rw-r--r-- 1 root root 11370269 Sep 16 11:29 xaf |
As you can see I actually ended up with 6 new files because I rounded the number of lines at which to split to 3300000. The last new file contains the leftovers. At this point you can archive your original large logfile and rename your new files to match your log naming scheme:
1 2 3 4 5 6 7 | mv access_log.1 old.access_log.1 mv xaa access_log.1 mv xab access_log.2 mv xac access_log.3 mv xad access_log.4 mv xae access_log.5 mv xaf access_log.6 |
Repeat the above for any large logfiles and you should be able to run analog against the new, smaller files with no problems.