Troubleshooting Linux log management services

Disclaimer: the article is applicable to the Standard Linux Shared Hosting, not to Linux Shared Hosting NG. Refer to the article #114326> for information about Linux Shared Hosting NG in OA.

Troubleshooting logparser service

Logparser service saves own log in the /usr/local/pem/bin/logparser.log file on a Linux Shared Hosting server by default, analyze the file to troubleshoot the problems with log parsing and traffic usage collecting in OA.

Typical problems are described below.

Customers' Apache logs are not being processed at all:

  • Make sure that the cronjob to run logparser service is configured in the /etc/crontab file on all Linux web hosting servers. Typically it is run as follows:

    0 2-23/3 * * * root /usr/local/pem/etc/web_cluster/isdirector.sh && /usr/local/pem/bin/logparser.sh >/dev/null 2>&1
    
  • Analyze logs of cron service to find out if the /usr/local/pem/bin/logparser.sh utility is being run in accordance with cron configuration file

Apache log file of a particular customer's webspace is not being processed.

Log format defined in the /usr/local/pem/etc/logparser/config.xml file does not match a particular log file format, logparser cannot parse log file properly. In this case the /usr/local/pem/bin/logparser.log file will contain the error message 'Parse error' like in the example below:

Parse error: wrong time string: '192.168.39.15 - - [22/Mar/2013:02:28:18 +0600]'

Open the /usr/local/pem/etc/logparser/config.xml file on the Linux Shared Hosting where the problem webspace is located and find the entry for the problem log file, it looks like this:

<logfile ascn_key="" id="2885">
  <path filemask="access_log" masktype="exact">/usr/local/pem/vhosts/100979/log</path>
  <format>%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\" %v</format>
  <actions>
    <action atype="1">
      <checkpoint>1363865494</checkpoint>
    </action>
    <action atype="1024">
      <checkpoint>1363865494</checkpoint>
    </action>
    <action atype="512">
      <checkpoint>1363934018</checkpoint>
      <options>-p -N 5 -o /usr/local/pem/vhosts/100979/webspace/webstat -n s766.provider.com -c /usr/local/pem/vhosts/100979/webspace/conf/webalizer.conf</options>
    </action>
  </actions>
  <classifiers>
    <classifier key="t"/>
  </classifiers>
  <associations>
    <association rti_id="52154" value=""/>
  </associations>
</logfile>

The example above describes the access_log file in the webspace #100979.

The <format> tag in the example above contains Apache log format which logparser expects to see in a log being processed. Open the problem log file and carefully compare expected log format from the config.xml file and actual log format. Apache log format on OA-managed server is defined in the /usr/local/pem/etc/apache/httpd.conf_pem file. Make sure that log formats in all three places are the same, use the log file format from the vhost.conf to correct other configuration files if necessary.

Remove bad entries from the Apache log file in a customer webspace and re-run logparser:

# /usr/local/pem/bin/logparser.sh

If there is no config.xml, you can create it:

  1. Obtain service_id from OA DB:

    plesk=> select service_id from services where host_id = <HOST_ID> and name like '%logparser%';
    
  2. For OA 5.4 and lower installations execute the command in OA core server:

    # /usr/local/pem/bin/log_config_ctl -f /usr/local/pem/etc/pleskd.props  dumpLogConfig <SERVICE_ID>
    

    In case installation is running OA 5.5 there you need to run API method:

    <?xml version='1.0'?><methodCall>
    <methodName>pem.syncServiceConfiguration</methodName>
        <params>
            <param>
                <value>
                    <struct>
                        <member>
                            <name>service_id</name>
                            <value><i4><SERVICE_ID></i4></value>
                        </member>
                    </struct>
                </value>
            </param>
        </params>
    </methodCall>
    

Troubleshooting log rotation service

If Apache logs in all customers' webspaces on a particualr Linux Shared Hosting server are not being rotated - analyze log files of the cron service to check whether logrotate is being run in accordance with the schedule, usually the logrotate service is configured to be run once a day.

If Apache logs in a particular webspace are not being rotated - check if corresponding entries are present in the /etc/logrotate.d/pem file like in the example below:

/usr/local/pem/vhosts/WEBSPACE_ID/log/*.processed { }

where WEBSPACE_ID is the ID of a problem customer's webspace.

Also, check if the corresponding entry is present in the /var/lib/logrotate.status log file on a server. The example of entries for successfully rotated logs in customer's webspace 100948 is provided below:

"/usr/local/pem/vhosts/100948/log/access_log.processed" 2013-3-22 "/usr/local/pem/vhosts/100948/log/error_log.processed" 2013-3-22 "/usr/local/pem/vhosts/100948/log/ssl_access_log.processed" 2013-3-22

The example above says that all Apache log files in the webspace 100948 were rotated on 2013-03-22.

Troubleshoot the cron service if necessary.

Troubleshooting Log Files Access service

Symptoms: a customer cannot get access to Apache log files in their webspace using the 'Show FTP Directory' link in OA CCP, the error message '530 Login is incorrect' is displayed.

Resolution steps are as follows.

  1. Make sure that FTP service is up and running on the problem Linux Shared Hosting server and start it if necessary:

    # /etc/init.d/proftpd status
    # /etc/init.d/proftpd start
    
  2. Find the name of the special FTP user which has access to Apache logs in OA Customer Control Panel at Website > click on any website in webspace > More Tools > Log Manager > FTP user field.

  3. Log on the Linux server in question by SSH as root. IP address of the server is shown on the Log Manager screen in OA CCP in the URL field.

  4. Analyze OA-managed ProFTPD configuration files /usr/local/pem/ftp/ftp_auth/VHOST_ID/passwd and /usr/local/pem/ftp/ftp_auth/VHOST_ID/group (where VHOST_ID is some internal ID generated by OA):

    • Check if the FTP user found on the step 1 is present in the passwd file
    • Make sure the FTP user is included into the pemsrv group in the group file
    • Add the user to the pemsrv group if it is absent - correct the group file.

    See the main Knowledgebase article #115790 Website Hosting: General information, Best Practices and Troubleshooting for more information.

Internal content