SuiteCRM 8.10 wymaga dwóch niezależnych procesów w tle. Pierwszy to cron, który co minutę uruchamia polecenie bin/console schedulers:run. Od niego zależą kampanie e-mail, workflow i import poczty przychodzącej. Drugi to worker Symfony Messenger (messenger:consume), który SuiteCRM 8.10 wprowadziło na potrzeby Async Tasks. Większość problemów z zadaniami w tle po aktualizacji ma jedną przyczynę: działa tylko jeden z tych procesów. Poniżej opisujemy konfigurację obu i procedurę diagnostyczną.

W skrócie: cron obsługuje schedulery, a worker Messenger obsługuje Async Tasks. Każdy z nich musi działać jako użytkownik serwera WWW. Stan obu da się sprawdzić w kilka minut: w widoku Schedulerów, poleceniem ps aux i w panelu Migrations.

Czym są schedulery w SuiteCRM 8 i które funkcje od nich zależą?

Schedulery w SuiteCRM 8 to zadania systemowe, które uruchamiają się cyklicznie według harmonogramu ustawionego w Administracja → Schedulery (sekcja System). Same z siebie się nie startują. Potrzebują zewnętrznego wyzwalacza, czyli crona systemu operacyjnego, który co minutę wywołuje bin/console schedulers:run. Przy każdym wywołaniu SuiteCRM sprawdza, którym aktywnym zadaniom przypada termin, i je wykonuje. Zadanie ze statusem Inactive nie uruchomi się nigdy, nawet przy poprawnie działającym cronie.

Poniższa tabela pokazuje, które funkcje biznesowe stoją za poszczególnymi schedulerami. Pozwala też rozpoznać problem po objawie zgłoszonym przez użytkowników.

Scheduler w SuiteCRM 8	Za co odpowiada	Objaw, gdy nie działa
Process Workflow Tasks	Zaplanowane akcje modułu Workflow	Workflow z warunkami czasowymi się nie uruchamiają, e-maile z workflow nie wychodzą
Check Inbound Mailboxes	Import poczty z kont przychodzących	Wiadomości nie trafiają do Cases ani do historii kontaktu
Queue Campaign Emails	Kolejkowanie zaplanowanych Email Marketing Records	Kampania nie przechodzi do wysyłki
Send Campaign Emails	Wysyłka zakolejkowanych e-maili kampanii	Kolejka rośnie, odbiorcy nic nie dostają
Run Nightly Process Bounced Campaign Emails	Przetwarzanie odbić z kont bounce	Statystyki kampanii są niepełne, błędne adresy nie są oznaczane
Run Report Generation Scheduled Tasks	Wysyłka raportów zaplanowanych	Raporty nie docierają do odbiorców
Run Email Reminder Notifications	Przypomnienia o aktywnościach	Brak przypomnień o spotkaniach i rozmowach
Prune Database on 1st of Month, Clean Up Temporary Files	Porządki w bazie i plikach tymczasowych	Rośnie baza i katalog plików tymczasowych

Ta różnica jest ważna przy migracji z SuiteCRM 7. W SuiteCRM 8 zadanie Run Nightly Mass Email Campaigns jest nieaktywne, a wysyłkę kampanii przejęły dwa schedulery: Queue Campaign Emails i Send Campaign Emails. Jeśli po migracji kampanie nie wychodzą, w pierwszej kolejności sprawdźcie status i datę ostatniego uruchomienia właśnie tych dwóch zadań. Od wersji 8.10 kampania, która przekroczy próg błędów SMTP w partii, przechodzi automatycznie w status Paused (SuiteCRM Release Notes 8.10, 2026).

Czym są Async Tasks w SuiteCRM 8.10 i czym różnią się od schedulerów?

Async Tasks to mechanizm zadań w tle wprowadzony w SuiteCRM 8.10, wydanym 30 kwietnia 2026 roku. Mechanizm opiera się na komponencie Symfony Messenger. Zadanie trafia do kolejki, a osobny, stale działający proces, czyli worker, pobiera je i wykonuje w małych partiach poza serwerem WWW. Operacje na tysiącach rekordów nie podlegają więc limitom czasu PHP ani przeglądarki. W wersji 8.10 z Async Tasks korzystają przede wszystkim Manual Migration Tasks, czyli migracje danych po aktualizacji. Dokumentacja wymienia też eksporty masowe.

Async Tasks nie zastępują schedulerów, tylko działają obok nich jako drugi kanał. Bez workera zadania asynchroniczne zostają w statusie Pending bez końca. Bez crona przestają działać kampanie, workflow i import poczty. Administrator, który po aktualizacji do SuiteCRM 8.10 skonfiguruje tylko jeden z tych mechanizmów, będzie miał system działający częściowo. Takie awarie są najtrudniejsze do zauważenia, bo interfejs nie pokazuje żadnego błędu.

Cecha	Schedulery (cron)	Async Tasks (worker Messenger)
Wyzwalanie	Cron co minutę uruchamia schedulers:run	Stały proces messenger:consume nasłuchuje kolejki
Charakter procesu	Krótkie, cykliczne uruchomienia	Proces działający długo, restartowany po limicie czasu lub pamięci
Kolejka	Tabela job_queue w bazie SuiteCRM	Domyślnie tabela messenger_messages (Doctrine), opcjonalnie Redis lub RabbitMQ
Typowe zadania	Workflow, kampanie, import poczty, raporty, porządki	Migracje danych po aktualizacji, eksporty masowe
Gdzie sprawdzić stan	Administracja → Schedulery	Administracja → Admin Tools → Migrations, log Messengera
Zarządca procesu	crontab	Supervisor (zalecany), systemd lub cron

Jak skonfigurować cron dla schedulerów w SuiteCRM 8?

Cron dla SuiteCRM 8 konfiguruje się w crontabie tego użytkownika, na którym działa serwer WWW. Wpis powinien uruchamiać się co minutę. Od SuiteCRM 8.9 dokumentacja wskazuje polecenie konsolowe bin/console schedulers:run. W starszych wersjach 8.x stosowano wywołanie cd [ścieżka]/public/legacy; php -f cron.php. Takie wpisy często zostają w crontabach po aktualizacjach, dlatego warto sprawdzić, który wariant działa na danej instancji.

1. Ustalcie użytkownika serwera WWW. Najczęściej to www-data (Debian/Ubuntu), apache lub nginx. W SuiteCRM wejdźcie w Administracja → Diagnostyka, wygenerujcie tylko phpinfo i odczytajcie wartość APACHE_RUN_USER. Nie używajcie do tego php -i z wiersza poleceń, bo pokazuje inny kontekst.
2. Otwórzcie crontab tego użytkownika poleceniem sudo crontab -e -u www-data.
3. Dodajcie wpis z pełną ścieżką do PHP CLI: * * * * * /usr/bin/php /var/www/suitecrm/bin/console schedulers:run > /dev/null 2>&1. Ścieżki dostosujcie do swojej instalacji.
4. Sprawdźcie allowed_cron_users w config.php. Użytkownik z crontaba musi być na tej liście. Instalator dodaje użytkownika serwera WWW automatycznie, ale nie dodaje roota.
5. Zweryfikujcie działanie. Na liście Schedulerów widget pokazuje ostatniego użytkownika, który uruchomił schedulery, oraz czas ostatniego udanego uruchomienia.

Fragment config.php z poprawną konfiguracją wygląda tak:

‘cron’ => array (
‘max_cron_jobs’ => 10,
‘max_cron_runtime’ => 30,
‘min_cron_interval’ => 30,
‘allowed_cron_users’ => array (
0 => ‘www-data’,
),
),

W mocno obciążonych systemach dokumentacja SuiteCRM dopuszcza uruchamianie crona co dwie minuty (*/2 * * * *). Ma to jednak swoją cenę. Zadania ustawione na wykonanie co minutę, np. Check Inbound Mailboxes, uruchomią się wtedy rzadziej, a import poczty do Cases opóźni się nawet o dodatkową minutę na cykl.

Jak uruchomić i utrzymać workera Messenger dla Async Tasks?

Worker Messenger to proces bin/console messenger:consume internal-async. W środowisku produkcyjnym musi działać bez przerwy i automatycznie restartować się po zatrzymaniu. Dokumentacja SuiteCRM zaleca do tego narzędzie Supervisor. Podobnie jak cron, worker musi działać jako użytkownik serwera WWW. W przeciwnym razie operacje na plikach, np. uploady i zapis obiektów media, kończą się błędami uprawnień.

1. Sprawdźcie tabelę kolejki. Tabela messenger_messages powstaje przy Administracja → Naprawa → Quick Repair & Rebuild. Jeśli jej brakuje, uruchomcie php bin/console messenger:setup-transports.
2. Zróbcie test ręczny: sudo -u www-data php bin/console messenger:consume internal-async –time-limit=3600 –memory-limit=256M -vv. Flaga -vv pokazuje każdą przetwarzaną wiadomość.
3. Utwórzcie konfigurację Supervisora w pliku /etc/supervisor/conf.d/suitecrm-messenger.conf (przykład poniżej).
4. Przeładujcie Supervisora: sudo supervisorctl reread, sudo supervisorctl update, sudo supervisorctl start suitecrm-messenger:*.
5. Opcjonalnie dostosujcie plik .env.local. Zmienna MESSENGER_INTERNAL_ASYNC_TRANSPORT_DSN wskazuje kolejkę (domyślnie doctrine://default?queue_name=internal_async). Zmienna MESSENGER_LOG_LEVEL steruje szczegółowością logów (domyślnie error).

[program:suitecrm-messenger]
command=php /var/www/suitecrm/bin/console messenger:consume internal-async –time-limit=3600 –memory-limit=256M
user=www-data
numprocs=1
autostart=true
autorestart=true
startsecs=0
startretries=10
process_name=%(program_name)s_%(process_num)02d
stderr_logfile=/var/log/supervisor/suitecrm-messenger.err.log
stdout_logfile=/var/log/supervisor/suitecrm-messenger.out.log

Parametr numprocs zostawcie na wartości 1, dopóki nie sprawdzicie, że wasze zadania można bezpiecznie przetwarzać współbieżnie. Kilka workerów naraz może przetworzyć to samo zadanie dwukrotnie. Jeśli serwer nie pozwala na Supervisora ani systemd, dokumentacja dopuszcza uruchamianie workera z crona co minutę z flagą –time-limit=55. To rozwiązanie jest mniej wydajne, bo między kolejnymi uruchomieniami kolejka przez chwilę nie jest przetwarzana.

Jak sprawdzić, czy schedulery i worker działają?

Diagnostykę zadań w tle w SuiteCRM 8 najlepiej prowadzić w stałej kolejności: najpierw interfejs, potem procesy systemowe, na końcu logi. Każdy krok wyklucza inną grupę przyczyn. Jeśli interfejs pokazuje świeże uruchomienie schedulerów, problem nie leży w cronie, tylko w konkretnym zadaniu albo jego konfiguracji. Jeśli w systemie brakuje procesu messenger:consume, nie ma sensu analizować logów migracji. Taka kolejność zwykle skraca diagnozę do kilku minut.

Co sprawdzić	Gdzie / jakim poleceniem	Jak czytać wynik
Ostatnie udane uruchomienie schedulerów	Widget na liście Administracja → Schedulery	Czas starszy niż kilka minut oznacza, że cron nie działa albo działa jako niedozwolony użytkownik
Stan konkretnego zadania	Widok szczegółów schedulera	Czas ostatniego uruchomienia aktualny, a funkcja nie działa: szukajcie błędu w logu
Wpis w crontabie	sudo crontab -l -u www-data	Brak wpisu, stary wariant z cron.php albo wpis u innego użytkownika
Uruchomienie ręczne	sudo -u www-data php bin/console schedulers:run	Błędy pojawiają się wprost w terminalu
Proces workera	ps aux | grep messenger:consume	Brak procesu oznacza, że zadania Async zostaną w statusie Pending
Stan migracji po aktualizacji	Administracja → Admin Tools → Migrations	Zadania w Pending przy działającym workerze: sprawdźcie log Messengera
Log Messengera	logs/prod/prod.messenger.log	Przy MESSENGER_LOG_LEVEL=info widać każdą wysłaną i przetworzoną wiadomość
Nieudane wiadomości	php bin/console messenger:failed:show	Ponowienie: messenger:failed:retry <id>
Logi aplikacji	logs/legacy/suitecrm.log i log błędów PHP	Błędy konkretnych zadań, w tym odrzucenie przez allowed_cron_users

Jakie błędy najczęściej blokują zadania w tle w SuiteCRM 8?

Najczęstsze przyczyny zatrzymanych zadań w tle w SuiteCRM 8 dotyczą użytkownika systemowego, wersji PHP i środowiska hostingowego. Rzadziej winna jest sama aplikacja. Poniższa lista obejmuje błędy opisane w dokumentacji SuiteCRM i zgłaszane na forum społeczności po wydaniu wersji 8.10.

• Cron uruchomiony jako root. Pliki cache utworzone przez roota blokują potem zapis serwerowi WWW. Samo poprawienie crontaba nie wystarczy. Trzeba przywrócić właściciela i uprawnienia w całym katalogu SuiteCRM, a potem wykonać Quick Repair and Rebuild.
• Użytkownik spoza allowed_cron_users. Skrypt kończy działanie przy każdym starcie, a w suitecrm.log co minutę pojawia się komunikat o tej liście. Rozwiązanie: dopisać użytkownika do tablicy w config.php.
• Konsola uruchamiana przez PHP CGI zamiast CLI. Ten problem jest typowy dla paneli hostingowych, np. cPanel. W logu crona pojawia się ostrzeżenie, że konsolę należy wywoływać przez CLI. Rozwiązanie: wskazać w poleceniu pełną ścieżkę do binarki PHP CLI.
• Hosting bez procesów działających długo. Worker Messenger potrzebuje procesu, który działa stale. Na hostingu współdzielonym zwykle zostaje wariant z cronem i –time-limit=55 albo przeniesienie instancji na VPS.
• Aktualizacja do 8.10 bez skonfigurowanego workera. Migracje zdjęć, załączników notatek i rewizji dokumentów zostają w statusie Pending. Obecne pliki nadal się wyświetlają dzięki mechanizmowi zgodności wstecznej, dlatego problem łatwo przeoczyć.
• Worker uruchomiony jako inny użytkownik niż serwer WWW. Kończy się to błędami uprawnień przy uploadach i zapisie plików media.
• E-maile z workflow po aktualizacji do 8.10 lub 8.10.1. Użytkownicy forum SuiteCRM zgłaszali, że workflow przestały wysyłać e-maile, mimo że wysyłka ręczna i kampanie działały. Poprawka (PR #974) weszła do wersji 8.10.2 z 31 lipca 2026 roku. Ta wersja zawiera też kilkadziesiąt poprawek bezpieczeństwa, więc aktualizacja jest wskazana niezależnie od workflow.

Co sprawdzić po przeczytaniu tego artykułu?

Najprostszy test kondycji zadań w tle w SuiteCRM 8.10 składa się z trzech kroków. Najpierw otwórzcie listę Schedulerów i porównajcie czas ostatniego udanego uruchomienia z bieżącą godziną. Potem wykonajcie na serwerze ps aux | grep messenger:consume. Na koniec zajrzyjcie do Administracja → Admin Tools → Migrations. Jeśli którykolwiek z tych punktów budzi wątpliwości, przejdźcie tabelę diagnostyczną od góry. Kiedy ostatnio ktoś w waszym zespole sprawdzał, kiedy schedulery uruchomiły się po raz ostatni?

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na Twoje pytania.

Najczęściej zadawane pytania