Debugging cPanel FTP logs when statistics do not update

I recently encountered a common but frustrating challenge for those who manage cPanel servers via the CLI: I performed several file transfers via FTP, confirmed that the files successfully reached their destination, but the logs within the user's home directory simply did not reflect any recent activity.

The specific path that caused the confusion was:

/home/user/logs

Inside this directory, there were compressed files following the standard naming convention:

ftp.domain.com-ftp_log-Mar-2026.gz

Even after uploading several megabytes of data via FTP, the size of these .gz files remained unchanged, and their modification dates appeared frozen in the past. To a casual observer, it might seem that Pure-FTPd had stopped logging or that cPanel's statistics processing system had crashed.

The core of this diagnosis was separating live logs from archives. A .gz file within /home/user/logs is not a real-time record of service activity. It is a historical package generated by periodic rotation and consolidation tasks. If you perform an upload now, you should not expect this archive to be updated instantly as if you were running a tail -f.

The scenario i encountered#

The user had multiple compressed log files, with names similar to the one mentioned above. The observed behavior pattern was:

• FTP transfers were marked as "Success" in FileZilla.
• Files correctly appeared in the target directory (e.g., public_html).
• The size and timestamp of the .gz files in /home/user/logs remained static.
• Executing runweblogs did not yield any recent activity indicators.

In this type of case, I don't start by assuming an FTP service failure. First, I validate the transfer itself. If the file exists and the client reported success, the FTP daemon worked. The question then shifts to:

Where did cPanel record the raw event, and when will it compress that into the user's home archive?

The runweblogs myth#

The first instinct for many cPanel administrators is to run:

/usr/local/cpanel/scripts/runweblogs <user>

I executed this command because it is an official script and often resolves delayed statistics. However, there is a critical operational lesson here: runweblogs primarily processes statistics for visual web-based tools like Awstats and Webalizer. It reads existing log data and generates reports.

It is not the component responsible for the instantaneous writing of FTP events into the .gz archives within the user's home.

If the raw log hasn't been rotated yet, if cpanellogd hasn't consolidated the data, or if the activity isn't in the specific file the script expects, runweblogs might return a confusing message, such as claiming there has been no activity since the Unix epoch.

The classic message looks like this:

No activity since 1969

This date doesn't mean the server traveled back in time. It typically indicates that the stats processor found no new, valid, or processable timestamps in its input set.

Raw logs vs. archives: the operational shift#

This was the turning point of the diagnosis. I began treating the .gz files as "dead" files from an operational perspective - they are archives representing the past, dependent on a maintenance task to be generated or refreshed.

The correct mental model is:

FTP service generates event -> System records in raw log -> cPanel processes/rotates -> Archive appears in /home/user/logs

The incorrect (and frustrating) expectation is:

FTP upload -> .gz archive changes immediately

To debug the "present," I stop looking at /home/user/logs/*.gz and move to raw system logs in /var/log, journald, and cPanel's temporary domlogs.

Auditing the service via journald#

On modern Linux distributions, especially when traditional files like /var/log/xferlog are absent, Pure-FTPd likely sends messages to syslog or journald.

The most direct command to follow the service in real-time is:

journalctl -u pure-ftpd -f

Using this, I can monitor connection attempts, logins, and uploads as they happen. The goal is to confirm:

• Did Pure-FTPd receive the connection?
• Was authentication successful?
• Did the PUT command arrive?
• Was the transfer completed without errors?
• Are there permission or session errors?

This removes a major variable. If journalctl shows the event, the FTP service is logging correctly. The problem is not "missing logs," but rather "unconsolidated logs."

Searching /var/log/messages#

In some environments, Pure-FTPd output is directed to the general system log. I search specifically for the name of the file I just transferred:

grep "file_name.txt" /var/log/messages

This search is objective. I don't look for generic "FTP" strings first; I look for the actual artifact. If I uploaded file_name.txt, its presence in the logs is an undeniable evidence of activity.

When /var/log/xferlog is missing#

Older documentation often points to /var/log/xferlog. While this file is perfect for tracking FTP when it exists, many modern cPanel configurations do not generate it by default or have moved away from it.

If you don't find it, don't panic. Simply pivot to:

journalctl -u pure-ftpd -f
grep "file_name.txt" /var/log/messages

And additionally, check cPanel's temporary domlogs area.

Domlogs: the missing link#

cPanel maintains temporary logs before they are processed and compressed into the home directory. A key location I check is:

ls -la /var/log/apache2/domlogs/<user>/

Despite the apache2 folder name, this path often centralizes logs per domain/user for various services used by the cPanel stats ecosystem. Finding activity here proves that the system has captured the event, it just haven't "packaged" it yet.

Forcing processing with cpanellogd#

When you need to force a processing pass, runweblogs isn't enough. You need cpanellogd, the daemon responsible for log rotation and processing across the server.

The operational command is:

/usr/local/cpanel/cpanellogd --one

If the binary isn't found, I quickly locate it:

which cpanellogd
# or
find /usr/local/cpanel -name cpanellogd -type f 2>/dev/null

This command triggers a maintenance pass. However, keep expectations realistic: and it still doesn't turn archives into live logs.

Common errors and solutions#

Forensic checklist#

My finalized troubleshooting flow for this incident:

1. Verify Artifact Presence: ls -lah /home/user/public_html/file_name.txt.
2. Review Home Logs: ls -lah /home/user/logs/.
3. Run Stats Wrapper: /usr/local/cpanel/scripts/runweblogs user.
4. Follow Live Service: journalctl -u pure-ftpd -f.
5. Grepping System Logs: grep "file_name.txt" /var/log/messages.
6. Inspect Temporary Storage: ls -la /var/log/apache2/domlogs/user/.
7. Force Log Consolidation: /usr/local/cpanel/cpanellogd --one.
8. Binary Validation: which cpanellogd.

Technical takeaway#

This incident highlighted a nuance that prevents significant wasted effort: /home/user/logs/*.gz represents processed history, not live activity. To debug the present, one must look at raw logs in /var/log, journalctl, and temporary areas like domlogs.

If the transfer is successful in the client and the file exists on the server, the FTP service has succeeded. The update of the .gz file is a periodic maintenance event, not an instant trigger. Separating live evidence from archived indicators is the key to a fast, accurate diagnosis in complex hosting environments.

See also

Infrastructure Debugging pure-ftpd stuck waiting for welcome message on cpanel/ovh

Servers The mystery of deleted files: tracking removals across cPanel, FTP, and PHP application layers

Infrastructure Crontab kernel mechanics, Linux logging differences, and Exim mail spool maintenance

This post is licensed under CC BY-NC.