Processes the task queue
It periodically runs background tasks queued by cPanel.
Diagnose “The queueprocd service is down”, “start operation timed out”, “status=9/KILL”, PID notification and NOTIFY_SOCKET errors through real log lines. Step by step use secure SSH commands that can be implemented on CloudLinux, AlmaLinux and Rocky Linux based cPanel servers.
$ systemctl status queueprocd
● queueprocd.service
Active: failed (Result: timeout)
Got notification message from PID...
$ check_cpanel_pkgs --fix
$ restartsrv_queueprocd
Active: active (running)
Status: "Ready"
queueprocd is the TaskQueue Processing Daemon service that processes jobs waiting in the cPanel and WHM task queue in the background. It helps to run maintenance, account, SSL and system tasks in order without waiting for the user request. The service is monitored by chkservd and attempts to auto-restart when found offline.
It periodically runs background tasks queued by cPanel.
If the service shuts down, chkservd performs a health check and calls the restart script.
queueprocd is different from the email sending queue; cPanel handles system tasks.
If the service is not running, tasks may accumulate and WHM operations may be delayed.
Type the error text you see in the email or SSH output into the search field below. Note that the XID values are the event tracking ID, not the error code.
The “queueprocd” service is down/usr/local/cpanel/scripts/restartsrv_queueprocdThe subprocess “restartsrv_queueprocd” reported error number 2journalctl -u queueprocd -n 100 --no-pagerstart operation timed out. Terminatingsystemctl show queueprocd -p Type -p NotifyAccess -p MainPID -p TimeoutStartUSecGot notification message from PID, but reception only permitted for main PID/usr/local/cpanel/scripts/check_cpanel_pkgs --fixMain process exited, code=killed, status=9/KILLjournalctl -k --since "30 minutes ago" | grep -Ei "oom|killed process|out of memory"Failed with result “timeout”systemctl status queueprocd -l --no-pagerState “stop-sigterm” timed out. Killingps auxf | grep "[q]ueueprocd"No cPanel TaskQueue Daemon detectedsystemctl status queueprocd -l --no-pagerThe “NOTIFY_SOCKET” environment variable is emptysystemctl cat queueprocdUnable to redirect stderrlsattr -i /usr/local/cpanel/logs/queueprocd.logCan’t open PID file /var/run/queueprocd.pidls -lah /var/run/queueprocd.pid /run/queueprocd.pid 2>/dev/nullToo many levels of symbolic linksreadlink -f /var/run/queueprocd.pidNo space left on devicedf -hT; df -ihqueueprocd - process - block_brute_force yüksek CPUfind /var/cpanel/taskqueue/groups -maxdepth 2 -type f | wc -lqueueprocd isn’t running at Cpanel/TaskQueue/Manager.pm/usr/local/cpanel/scripts/restartsrv_queueprocd --statusXID 86gdh5, XID 8tut77 ve benzeri değerlergrep -R "XID" /usr/local/cpanel/logs/error_log | tail -n 20RECOVERED: queueprocdsystemctl is-active queueprocdThese commands do not modify the service file and do not delete the task queue. It should be used to see the root cause before intervention.
/usr/local/cpanel/cpanel -V
cat /etc/redhat-release 2>/dev/null || cat /etc/os-releasesystemctl status queueprocd -l --no-pager
/usr/local/cpanel/scripts/restartsrv_queueprocd --statusjournalctl -u queueprocd -n 100 --no-pagertail -n 150 /usr/local/cpanel/logs/queueprocd.logps auxf | grep '[q]ueueprocd'systemctl cat queueprocd
systemctl show queueprocd -p Type -p NotifyAccess -p ExecStart -p MainPID -p PIDFile -p TimeoutStartUSec -p FragmentPathdf -hT
df -ih
free -h
uptimejournalctl -k --since "1 hour ago" | grep -Ei "oom|out of memory|killed process"tail -n 100 /var/log/chkservd.logThe safest approach is to first retrieve the logs, verify the cPanel packages, clear the systemd state, and restart the service with cPanel's own script.
If the service is constantly being restarted, first record the status, journal, process, and queueprocd logs. This way, the actual error does not get lost during the restart.
systemctl status queueprocd -l --no-pager
journalctl -u queueprocd -n 100 --no-pager
tail -n 150 /usr/local/cpanel/logs/queueprocd.log
ps auxf | grep '[q]ueueprocd'Scans for missing, modified, or corrupted cPanel-managed packages. If no issues are found, the command may complete without output.
/usr/local/cpanel/scripts/check_cpanel_pkgs --fixPaket onarımından sonra systemd servis tanımlarını yeniden okutur ve eski failed durumunu temizler.
systemctl daemon-reload
systemctl reset-failed queueprocdUse the official restart script provided by cPanel. If graceful restart fails, try a controlled forced restart script.
/usr/local/cpanel/scripts/restartsrv_queueprocdIt is not enough for the service to only exist as a process; systemd active/running and preferably Status: Ready should be displayed.
sleep 10
systemctl status queueprocd -l --no-pager
systemctl is-active queueprocd
/usr/local/cpanel/scripts/restartsrv_queueprocd --statusIn the example case, while systemd saw the initiator process as the main PID, the READY notification came from the child queueprocd process. The service remained in activating state for 90 seconds, then was shut down with status=9/KILL. RAM and disk capacity were sufficient.
Applied solution: cPanel package verification, daemon-reload, clearing failed status and official restart script. After all, the service active (running) and Status: "Ready" went into status.
/usr/local/cpanel/scripts/check_cpanel_pkgs --fix
systemctl daemon-reload
systemctl reset-failed queueprocd
/usr/local/cpanel/scripts/restartsrv_queueprocd
sleep 10
systemctl status queueprocd -l --no-pagerOnly execute each command if the relevant error is clearly visible in the log. Moving the task queue, editing the service file, and upcp operations require a maintenance plan.
If Type=forking is seen in the output of systemctl cat queueprocd, the solution is to use Type=notify as described in cPanel documentation. Back up the service file before making the change.
cp -av /etc/systemd/system/queueprocd.service /root/queueprocd.service.yedek
sed -i 's/^Type=forking$/Type=notify/' /etc/systemd/system/queueprocd.service
systemctl daemon-reload
/usr/local/cpanel/scripts/restartsrv_queueprocdFirst, check the immutable bit of the log file. If the output contains the letter i, remove this bit in the way recommended by cPanel and restart the service.
lsattr -i /usr/local/cpanel/logs/queueprocd.log
chattr -i /usr/local/cpanel/logs/queueprocd.log
/usr/local/cpanel/scripts/restartsrv_queueprocdFind out which directory the fullness originated from before starting the deletion process. Especially check Taskqueue, log, and backup directories.
df -hT
df -ih
du -xhd1 /var 2>/dev/null | sort -h | tail -n 20
du -xhd2 /var/cpanel/taskqueue 2>/dev/null | sort -h | tail -n 20If Queueprocd -pr is using high CPU and cphulk_block_brute_force tasks reach tens of thousands of files, back up first. Moving the queue affects pending tasks and should only be applied by advanced administrators.
tar -C /var/cpanel -czf /root/taskqueue-yedek-$(date +%F-%H%M).tar.gz taskqueue
mv -v /var/cpanel/taskqueue /var/cpanel/taskqueue.$(date +%s)
/usr/local/cpanel/scripts/restartsrv_queueprocdPID dosyasını doğrudan silmeden önce gerçek süreçleri ve bağlantı hedefini doğrulayın. Çalışan bir daemon varken PID dosyasını silmek servis takibini bozabilir.
ps auxf | grep '[q]ueueprocd'
ls -lah /var/run/queueprocd.pid /run/queueprocd.pid 2>/dev/null
readlink -f /var/run/queueprocd.pid 2>/dev/nullYou can force a cPanel update during the maintenance time when the server load is low. This process can restart cPanel components and some services.
/usr/local/cpanel/scripts/upcp --force
systemctl daemon-reload
systemctl reset-failed queueprocd
/usr/local/cpanel/scripts/restartsrv_queueprocdChkservd recovery email is a positive sign. Still systemd and cPanel service control should be verified together.
Errornın nedenini görmeden /var/cpanel/taskqueue dizinini silmeyin.
Do not ignore the status=9/KILL line when RAM is empty.
Do not edit the main cPanel service file without backing it up.
Do not just silence the email alert and hide the real service issue.
Do not delete the PID file or lock files without verifying the running processes.
Do not start upcp --force or extensive package repair during peak hours.
This guide has been prepared with service, log and package repair information in cPanel, WHM and systemd official documentation. If your server version is different, check the updated documentation.
queueprocd is the TaskQueue Processing Daemon service that processes background jobs waiting in the cPanel and WHM task queue. It helps to execute SSL, account, maintenance, and various cPanel operations in the background without delaying user requests.
No. queueprocd processes the cPanel task queue. Exim mail queue is a different system and service.
It never shuts down websites directly. However, background tasks in cPanel can accumulate, WHM operations may be delayed, and if a service issue occurs alongside other system problems, administrative actions might be impacted.
Reports that the restart command failed. To learn the root cause, journalctl, Startup Log, and /usr/local/cpanel/logs/queueprocd.log should be examined.
No. Systemd can terminate the timed-out process itself with SIGKILL. Whether it is OOM or not must be verified with the kernel log's Out of memory or Killed process lines.
Checks for missing, outdated, or modified files in packages managed by cPanel and automatically fixes detected package issues. If no issues are found, it may exit without output.
First, you need to verify cPanel packages with check_cpanel_pkgs --fix, reload systemd configuration, and restart the queueprocd service with the cPanel script. Persistent service file changes should not be the first step.
No. First, the official service definition, cPanel packages, and Type=notify status must be checked. NotifyAccess changes should only be considered as a temporary and documented intervention in a verified private systemd PID notification issue.
The main queueprocd log is located at /usr/local/cpanel/logs/queueprocd.log. Systemd start and stop logs can be viewed with the command journalctl -u queueprocd.
Chkservd has detected that the service is running again and has passed its health check. Nevertheless, it is useful to verify the 'active running' and 'Status Ready' values in the systemctl status output.
Usually no. First perform package verification, daemon-reload, reset-failed, and the cPanel restart script. Restart should be a last resort.
Basic diagnostic commands are the same in Systemd-based cPanel servers. However, the service file and package status may vary depending on the cPanel version, so changes should not be made without checking the current output.
You can get log-based server analysis and optimization support for Queueprocd, chkservd, Apache, LiteSpeed, PHP-FPM, MariaDB and CloudLinux problems.
Instead of temporarily stopping the service, determine technically whether the error is caused by a package, process, disk, PID or task queue.
Get Technical SupportFirst, review the logs, verify cPanel packages, clear systemd state and use the official restart script. Apply advanced interventions only when the relevant fault is confirmed.