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.
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.
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
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.
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
There are Apache access and error logs for both the server and user accounts.
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.
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
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"
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!
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.
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.
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)
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
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.
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=
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.
Most of our cPanel servers use the ConfigServer Security & Firewall (CSF). As the name suggests, this is a security application and firewall.
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.
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
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.
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.