This article covers the most important log files on cPanel servers. The files include the “traditional” syslog files, as well as log files used by cPanel, Apache and CSF:

It is worth noting that log entries for some services, including Dovecot and Pure-FTPd, can also be inspected via the journalctl utility.

cPanel-specific logs

There are quite a few cPanel-specific log files in the /usr/local/cpanel/logs directory. We will only describe the most common logs. Please consult the official cPanel documentation for information about other log files in the directory.

/usr/local/cpanel/logs/access_log

cPanel’s access_log stores all cPanel HTTP requests. For instance, when a user logs in to their control panel or web mail all requests are logged in this file.

The log has the same format as the default Apache access log. As the third field in the access log is the username you can use utilities such as awk and grep to get specific information. For instance, here we see the user example deleting a mailbox:

# awk '$3 == "example" { print $0 }' /usr/local/cpanel/logs/access_log | grep POST.*delete
12.34.56.78 - example [09/10/2019:17:59:00 -0000] "POST /cpsess3678107429/execute/Email/delete_pop HTTP/1.1" 200 0 "https://strawberry.active-ns.com:2083/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0" "s" "-" 2083

/usr/local/cpanel/logs/error_log

cPanel-related errors are logged to the error_log file. This log is a good starting point when you are debugging an issue with cPanel.

/usr/local/cpanel/logs/login_log

cPanel login errors are written to the login_log file. This includes failed logins for web mail. Here we can see that the user info@example.net tried to log in to web mail using an incorrect password:

[2019-09-09 15:03:19 +0100] info [webmaild] 12.34.56.78 - info@example.net "POST /login/?login_only=1 HTTP/1.1" FAILED LOGIN webmaild: user password incorrect

Apache logs

There are Apache access and error logs for both the server and user accounts.

/etc/apache2/logs/domlogs/

Access logs for cPanel user accounts are stored in /etc/apache2/logs/domlogs/$USER. As this directory is outside the user’s home directory there is a symbolic link to the directory in the user’s home directory:

$ ls -l /home/example/access-logs
lrwxrwxrwx 1 example example 33 Jan 1  2019 /home/example/access-logs -> /etc/apache2/logs/domlogs/example

If a website has an SSL certificate there will be at least two logs: one log with the same name as the domain name (i.e. example.net) and a second log with the domain name and -ssl_log appended to the file name (i.e. example.net-ssl_log). The logs are for requests over port 80 and 443, respectively.

User error logs

PHP notices, warnings and errors for individual domains are written to error_log files. By default, the messages are written to an error_log file in the directory of the script that triggered the message. This means that there may be multiple error_log files.

If you are debugging a PHP error, you can search for error_log files using cPanel’s file manager. If you got SSH access then you can use the find utility instead:

$ find /home/$USER/public_html -type f -name error?log

In the above command we used a question mark to match any single character. This returns all error_log files, as well as files with names like error.log.

If there are lots of error log files, you can of course only list files that have changed in, say, the last 30 minutes:

$ find /home/$USER/public_html -type f -name error?log -mmin -30

/usr/local/apache/logs/access_log

The global access log file for Apache is /usr/local/apache/logs/access_log. The log file contains entries for HTTP requests for the server. Requests for websites that have been suspended or which don’t exist on the server also appear in this file.

$ grep foo.com /usr/local/apache/logs/access_log
12.34.56.78 - - [10/Sep/2019:19:03:53 +0100] "GET /img-sys/IP_changed.png HTTP/1.1" 200 2939 "http://foo.com/cgi-sys/defaultwebpage.cgi" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0"

/usr/local/apache/logs/error_log

Apache and ModSecurity errors are stored in /usr/local/apache/logs/error_log. If your server is running LiteSpeed and you are using brute-force protection then you will also find entries like these:

2019-09-10 20:49:53.530921 [NOTICE] [4027] [12.34.56.78] bot detected for vhost [APVH_example.net], reason: WordPressBruteForce, close connection!

System logs

Historically, Linux keeps most log files in the /var/log directory. Linux systems based on RHEL 7 and 8, such as Centos and CloudLinux, use the systemd-journald service to manage logs for services. However, there are still relevant logs in the /var/log directory.

/var/log/messages

The /var/log/messages log contains entries for FTP (usually pure-ftpd), nameserver deamons such as named (Bind) or pdns (PowerDNS) and the SSH daemon (sshd).

The FTP entries are likely to be of interest most, as they are useful to debug FTP errors. For instance, below is an entry for a TLS error:

Sep 10 21:53:49 strawberry pure-ftpd: (?@12.34.56.78) [INFO] New connection from 12.34.56.78
Sep 10 21:53:49 strawberry pure-ftpd: (?@12.34.56.78) [WARNING] Sorry, cleartext sessions and weak ciphers are not accepted on this server. Please reconnect using TLS security mechanisms.

/var/log/secure

SSH login attempts are kept in /var/log/secure. We always require customers to connect via a VPN, which prevents the server from being hammered by SSH login attempts. However, if there are any failed logins then they will appear in the log like so:

Sep 10 21:09:30 server sshd[23114]: Received disconnect from 12.34.56.78 port 15180:11: [preauth]
Sep 10 21:09:30 server sshd[23114]: Disconnected from 12.34.56.78 port 15180 [preauth]q

And this is a successful login:

Sep 10 18:36:20 example sshd[1306]: Accepted password for example from 12.34.56.78 port 12345 ssh2
Sep 10 18:36:20 example sshd[1306]: pam_unix(sshd:session): session opened for user example by (uid=0)

/var/log/cron

The log file for cron jobs is /var/log/cron. The file logs when cron jobs ran for both the root user and system users:

# grep example /var/log/cron
Sep 10 20:00:01 strawberry CROND[43192]: (example) CMD (php /home/example/public_html/cron/cron.php)
Sep 10 20:30:01 strawberry CROND[16496]: (example) CMD (php /home/example/public_html/cron/cron.php)
Sep 10 21:00:01 strawberry CROND[27539]: (example) CMD (php /home/example/public_html/cron/cron.php)

It is worth noting that cron errors are not written to the log. By default, cron errors are instead sent to the user via email. If you are looking in to a cron error, you can check where the emails are sent by viewing the user’s crontab file:

# crontab -l -u example
MAILTO="info@example.net"
SHELL="/bin/bash"
45 12 * * * php -q /home/example/cron/cron.php

Email logs

cPanel servers uses Dovecot as the IMAP/POP3 daemon and Exim as the Mail Transfer Agent. For IMAP/POP3 errors you can check the /var/log/maillog file, and for SMTP errors you can inspect /var/log/exim_mainlog.

/var/log/maillog

The /var/log/maillog file mainly shows connection information, including authentication errors. The below is an example of a login failure for info@example.net. The login came from the IP address 12.34.56.78 (okay, we changed the IP address).

Sep 10 19:52:07 strawberry dovecot: imap-login: Disconnected (auth failed, 1 attempts in 6 secs): user=<info@example.net>, method=PLAIN, rip=12.34.56.78, lip=84.18.206.207, TLS: Connection closed, session=<MJdZZjeS+4HaHKTa>

Another thing to look out for in this log are TLS errors. You will see an error like this when a client is connecting to the mail server using an operating system and/or email client that doesn’t support current TLS standards:

Sep 10 19:40:51 strawberry dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=12.34.56.78, lip=84.18.206.207, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=

/var/log/exim_mainlog

As said, the main Exim log file is /var/log/exim_mainlog. The log provides detailed information about email deliveries. To give an example, in the article about email filters in cPanel we sent an email from sales@unicornfactory.ru to info@example.net. The email was delivered twice: it was stored in the spam folder and in a folder named Unicorns. This is the log entry for the email:

# exigrep info@example.net /var/log/exim_mainlog
2019-09-08 13:08:53 1i6vzx-000068-S8 <= sales@unicornfactory.ru H=(strawberry.active-ns.com) [::1]:47280 P=esmtpa A=dovecot_login:sales@unicornfactory.ru S=696 id=80f389eeed39b66128035e71342a9270@unicornfactory.ru T="Alternative payment options" for info@example.net 2019-09-08 13:08:54 1i6vzx-000068-S8 => info+spam ("info+Unicorns"@example.net, "info+spam"@example.net) <info@example.net> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <info+spam@example.net> iO47OVXvdF1qfAAAMFInxw Saved"
2019-09-08 13:08:54 1i6vzx-000068-S8 -> info+unicorns ("info+Unicorns"@example.net, "info+spam"@example.net) <info@example.net> R=virtual_user T=dovecot_virtual_delivery C="250 2.0.0 <info+Unicorns@example.net> iO47OVXvdF1qfAAAMFInxw:2 Saved"
2019-09-08 13:08:54 1i6vzx-000068-S8 Completed

In the same article we also showed how emails may be purged by a filter. The below log entry shows the email was delivered to /dev/null. On Linux, anything sent to /dev/null disappears into a black hole.

2019-09-08 13:13:59 1i6w4t-0000rY-23 <= sales@unicornfactory.ru H=(strawberry.active-ns.com) [::1]:48006 P=esmtpa A=dovecot_login:sales@unicornfactory.ru S=688 id=f11c7ea320f015bbb428cfe26c836043@unicornfactory.ru T="Alternative payment options (chasing)" for info@example.net 2019-09-08 13:13:59 1i6w4t-0000rY-23 => /dev/null <info@example.net> R=virtual_user_filter T=**bypassed**

Of course, authentication errors are also logged:

2019-09-08 13:17:27 dovecot_plain authenticator failed for ([12.34.56.78]) [12.34.56.78]:44470: 535 Incorrect authentication data (set_id=infoo@example.net)

As an aside, it is worth noting that you can use the exigrep utility to search the file. The utility works just like grep but it formats the log entries in a more readable way.

CSF

Most of our cPanel servers use the ConfigServer Security & Firewall (CSF). As the name suggests, this is a security application and firewall.

/var/log/lfd.log

One of CSF’s jobs is to prevent brute-force login attempts. CSF uses a Login Failure Daemon (LFD), which monitors for failed logins, and LFD’s log file is /var/log/lfd.log. The file logs any failed login attempts, as well as IP addresses that have been blocked by CSF.

/etc/csf/csf.deny

The /etc/csf/csf.deny log lists IP addresses that have been blocked. For each entry it shows the date the IP address was blocked and the reason. For instance, here is an IP address that was blocked because of failed SMTP login attempts:

220.171.104.210 # lfd: (smtpauth) Failed SMTP AUTH login from 220.171.104.210 (CN/China/-): 5 in the last 3600 secs - Tue Sep 10 11:14:38 2019

/etc/csf/csf.allow

The /etc/csf/csf.allow file lists IP addresses that have been whitelisted. Failed login attempts for these IP addresses will still appear in /var/log/lfd.log but they are not added to the /etc/csf/csf.deny file.

Each entry lists the IP address, a comment that explains why the IP address was whitelisted, the geolocation of the IP address and the date it was whitelisted:

12.34.56.78 # Manually allowed: 12.34.56.78 (GB/United Kingdom/-) - Mon Oct 29 13:17:08 2018

As an aside, CSF comes with a csf command line utility. It has a few useful options. For instance, you can check if an IP address has been blocked using csf -g:

# csf -g 220.171.104.214

Table  Chain            num   pkts bytes target     prot opt in     out     source               destination

filter DENYIN           105      9   716 DROP       all  --  !lo    *       220.171.104.214      0.0.0.0/0

filter DENYOUT          105     12  1538 LOGDROPOUT  all  --  *      !lo     0.0.0.0/0            220.171.104.214


ip6tables:

Table  Chain            num   pkts bytes target     prot opt in     out     source               destination
No matches found for 220.171.104.214 in ip6tables

csf.deny: 220.171.104.214 # lfd: (smtpauth) Failed SMTP AUTH login from 220.171.104.214 (CN/China/-): 5 in the last 3600 secs - Tue Sep 10 11:14:38 2019

If you are not sure whether or not to block an IP address you can check the geolocation using csf -i. Often, the geolocation gives a hint as to whether or not an IP address is making legitimate requests.

# csf -i 186.151.201.50
186.151.201.50 (GT/Guatemala/50.201.151.186.static.intelnet.net.gt)

And you can of course also block an IP address (csf -d $IP) or allow it (csf -a $IP). These options add the IP address to the /etc/csf/csf.deny and /etc/csf/csf.allow file, respectively.

Graphical interface

If CSF is installed on your server then you can blacklist or whitelist IP addresses via Plugins > ConfigServer Security & Firewall. The interface also lets you search various log files via the Search System Logs options. The log files you can search including the Apache, Dovecot and Exim logs.