Turkey (Türkçe)
Germany (German)
Worldwide (English)
Görev kuyruğunu işler
cPanel tarafından sıraya alınan arka plan görevlerini periyodik olarak çalıştırır.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
“The queueprocd service is down”, “start operation timed out”, “status=9/KILL”, PID bildirimi ve NOTIFY_SOCKET hatalarını gerçek log satırları üzerinden teşhis edin. CloudLinux, AlmaLinux ve Rocky Linux tabanlı cPanel sunucularında uygulanabilecek güvenli SSH komutlarını adım adım kullanın.
$ 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, cPanel ve WHM görev kuyruğunda bekleyen işleri arka planda işleyen TaskQueue Processing Daemon servisidir. Kullanıcı isteğini bekletmeden yürütülmesi gereken bakım, hesap, SSL ve sistem görevlerinin sırayla çalıştırılmasına yardımcı olur. Servis, chkservd tarafından izlenir ve çevrimdışı bulunduğunda otomatik yeniden başlatılmaya çalışılır.
cPanel tarafından sıraya alınan arka plan görevlerini periyodik olarak çalıştırır.
Servis kapanırsa chkservd sağlık kontrolü yapar ve yeniden başlatma betiğini çağırır.
queueprocd, e-posta gönderim kuyruğundan farklıdır; cPanel sistem görevlerini işler.
Servis çalışmazsa görevler birikebilir ve WHM işlemleri gecikebilir.
Aşağıdaki arama alanına e-postada veya SSH çıktısında gördüğünüz hata metnini yazın. XID değerlerinin hata kodu değil, olay takip kimliği olduğunu unutmayın.
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 queueprocdBu komutlar servis dosyasını değiştirmez ve görev kuyruğunu silmez. Müdahaleden önce kök nedeni görmek için kullanılmalıdır.
/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.logEn güvenli yaklaşım önce logları almak, cPanel paketlerini doğrulamak, systemd durumunu temizlemek ve servisi cPanel’in kendi betiğiyle yeniden başlatmaktır.
Servis sürekli yeniden başlatılıyorsa ilk olarak durum, journal, süreç ve queueprocd günlüklerini kaydedin. Böylece asıl hata yeniden başlatma sırasında kaybolmaz.
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'Eksik, değiştirilmiş veya bozuk cPanel yönetimli paketleri tarar. Sorun bulunmazsa komut çıktı vermeden bitebilir.
/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 queueprocdcPanel tarafından sağlanan resmi restart betiğini kullanın. Graceful restart başarısız olursa betik kontrollü bir forced restart deneyebilir.
/usr/local/cpanel/scripts/restartsrv_queueprocdServisin yalnızca süreç olarak bulunması yeterli değildir; systemd active/running ve mümkünse Status: Ready göstermelidir.
sleep 10
systemctl status queueprocd -l --no-pager
systemctl is-active queueprocd
/usr/local/cpanel/scripts/restartsrv_queueprocd --statusÖrnek vakada systemd ana PID olarak başlatıcı süreci görürken READY bildirimi alt queueprocd sürecinden geldi. Servis 90 saniye boyunca activating durumunda kaldı, ardından status=9/KILL ile kapatıldı. RAM ve disk kapasitesi yeterliydi.
Uygulanan çözüm: cPanel paket doğrulaması, daemon-reload, failed durumunun temizlenmesi ve resmi restart betiği. Sonuçta servis active (running) ve Status: "Ready" durumuna geçti.
/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-pagerHer komutu yalnızca ilgili hata logda açıkça görülüyorsa uygulayın. Görev kuyruğunu taşıma, servis dosyasını düzenleme ve upcp işlemleri bakım planı gerektirir.
systemctl cat queueprocd çıktısında Type=forking görülüyorsa cPanel dokümantasyonundaki çözüm Type=notify kullanılmasıdır. Değişiklikten önce servis dosyasını yedekleyin.
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_queueprocdÖnce log dosyasının immutable bitini kontrol edin. Çıktıda i harfi varsa cPanel’in önerdiği şekilde bu biti kaldırıp servisi yeniden başlatın.
lsattr -i /usr/local/cpanel/logs/queueprocd.log
chattr -i /usr/local/cpanel/logs/queueprocd.log
/usr/local/cpanel/scripts/restartsrv_queueprocdSilme işlemine başlamadan önce doluluğun hangi dizinden kaynaklandığını bulun. Taskqueue, log ve yedek dizinlerini özellikle kontrol edin.
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 20Queueprocd -pr yüksek CPU kullanıyor ve cphulk_block_brute_force görevleri on binlerce dosyaya ulaşıyorsa önce yedek alın. Kuyruğu taşımak bekleyen görevleri etkiler ve yalnızca ileri düzey yöneticilerce uygulanmalıdır.
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/nullSunucu yükünün düşük olduğu bakım saatinde cPanel güncellemesini zorlayabilirsiniz. İşlem cPanel bileşenlerini ve bazı servisleri yeniden başlatabilir.
/usr/local/cpanel/scripts/upcp --force
systemctl daemon-reload
systemctl reset-failed queueprocd
/usr/local/cpanel/scripts/restartsrv_queueprocdChkservd kurtarma e-postası olumlu bir işarettir. Yine de systemd ve cPanel servis kontrolü birlikte doğrulanmalıdır.
Hatanın nedenini görmeden /var/cpanel/taskqueue dizinini silmeyin.
RAM boşken status=9/KILL satırını otomatik olarak OOM hatası kabul etmeyin.
Ana cPanel servis dosyasını yedek almadan düzenlemeyin.
Sadece e-posta uyarısını kapatıp gerçek servis sorununu gizlemeyin.
Çalışan süreçleri doğrulamadan PID dosyasını veya lock dosyalarını silmeyin.
Yoğun saatte upcp --force veya geniş paket onarımı başlatmayın.
Bu rehber cPanel, WHM ve systemd resmi belgelerindeki servis, log ve paket onarım bilgileriyle hazırlanmıştır. Sunucu sürümünüz farklıysa güncel belgeyi kontrol edin.
queueprocd, cPanel ve WHM görev kuyruğunda bekleyen arka plan işlerini işleyen TaskQueue Processing Daemon servisidir. SSL, hesap, bakım ve çeşitli cPanel işlemlerinin kullanıcı isteğini bekletmeden arka planda yürütülmesine yardımcı olur.
Hayır. queueprocd cPanel görev kuyruğunu işler. Exim e-posta kuyruğu farklı bir sistem ve servistir.
Her zaman doğrudan web sitelerini kapatmaz. Ancak cPanel arka plan görevleri birikebilir, WHM işlemleri gecikebilir ve servis sorunu başka sistem problemleriyle birlikte görülüyorsa yönetim işlemleri etkilenebilir.
Yeniden başlatma komutunun başarısız olduğunu bildirir. Kök nedeni öğrenmek için journalctl, Startup Log ve /usr/local/cpanel/logs/queueprocd.log incelenmelidir.
Hayır. Systemd zaman aşımına uğrayan süreci kendisi SIGKILL ile kapatabilir. OOM olup olmadığını kernel günlüğündeki Out of memory veya Killed process satırlarıyla doğrulamak gerekir.
cPanel tarafından yönetilen paketlerde eksik, eski veya değiştirilmiş dosyaları kontrol eder ve tespit edilen paket sorunlarını otomatik olarak düzeltir. Sorun bulmazsa çıktı vermeden bitebilir.
Önce cPanel paketlerini check_cpanel_pkgs --fix ile doğrulamak, systemd yapılandırmasını yeniden yüklemek ve queueprocd servisini cPanel betiğiyle yeniden başlatmak gerekir. Kalıcı servis dosyası değişikliği ilk adım olmamalıdır.
Hayır. Önce resmi servis tanımı, cPanel paketleri ve Type=notify durumu kontrol edilmelidir. NotifyAccess değişikliği yalnızca doğrulanmış özel bir systemd PID bildirim sorununda geçici ve belgelenmiş bir müdahale olarak düşünülmelidir.
Ana queueprocd günlüğü /usr/local/cpanel/logs/queueprocd.log yolundadır. Systemd başlangıç ve kapanış kayıtları journalctl -u queueprocd komutuyla görüntülenir.
Chkservd servisin yeniden çalıştığını ve sağlık kontrolünden geçtiğini tespit etmiştir. Yine de systemctl status çıktısında active running ve Status Ready değerlerini doğrulamak faydalıdır.
Genellikle hayır. Önce paket doğrulama, daemon-reload, reset-failed ve cPanel restart betiği uygulanmalıdır. Yeniden başlatma son seçenek olmalıdır.
Systemd tabanlı cPanel sunucularında temel teşhis komutları aynıdır. Ancak servis dosyası ve paket durumu cPanel sürümüne göre değişebileceği için mevcut çıktılar kontrol edilmeden körlemesine değişiklik yapılmamalıdır.
Queueprocd, chkservd, Apache, LiteSpeed, PHP-FPM, MariaDB ve CloudLinux sorunlarında log tabanlı sunucu analizi ve optimizasyon desteği alabilirsiniz.
Servisi geçici olarak ayağa kaldırmak yerine hatanın paket, süreç, disk, PID veya görev kuyruğu kaynaklı olup olmadığını teknik olarak belirleyin.
Teknik Destek AlÖnce logları inceleyin, cPanel paketlerini doğrulayın, systemd durumunu temizleyin ve resmi restart betiğini kullanın. İleri düzey müdahaleleri yalnızca ilgili hata doğrulandığında uygulayın.