Synchronizacja oraz wysyłanie poczty w tle

Aby poczta z serwerów IMAP mogła być pobierana automatycznie należy uruchomić na serwerze dodatkowy proces który zapewniał będzie tą synchronizację.

Uruchomienie:

1. Zainstalować moduł SQLite (wersja 3) dla PHP (na windows powinno wystarczyć dodanie/odkomentowanie wpisu w php.ini - extension=php_sqlite3.dll)

lub

apt-get install php5-sqlite

2. Katalogi + Uprawnienia
   

ramdisk dla bazy sqlite + pid:

vim /etc/fstab

tmpfs /home/edokumenty/public_html/apps/backproc/data tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M 0 0

uprawnienia:

cd /home/edokumenty/public_html/apps/backproc
chown -R www-data:edokumenty data logs pid
chmod -R u+rwX,g+rwXs,o-rwx data logs pid

3. Uruchomienie procesu
   1. Harmonogram zadań (Windows)

   2. Dodanie do pliku /etc/crontab (Linux) poniższego wpisu

      */5 * * * * www-data php /home/edokumenty/public_html/apps/backproc/engine.php 2>&1 &
      

4. w pliku (apps/edokumenty/config.inc) ustawiamy dwie stałe:

   define('EMAIL_OUTBOX_ENABLED', TRUE);
   define('EMAIL_BACKGROUND_SYNC_ENABLED', TRUE);
   

Weryfikacja

Po pierwsze na liście procesów powinien widnieć uruchomiony proces php.

Po drugie proces ten zapisuje swoją aktywność do logów w: /home/edokumenty/public_html/apps/backproc/logs

Znajdują się tam 3 logi:

l-debug.log 
l-info.log  
l-threading-error.txt

Można w nich prześledzić jak odbierane są maile. Jeżeli l-info.log nie jest pusty, znaczy to, że procesy są uruchomione.

l-info.log:
[2014-01-12 22:28:05][#13817.t12] received 31468 new messages in 432s [53,824]
[2014-01-12 22:28:05][#13817.t12] received 0 new messages in 0s [53,825]
format:
[data operacji][#{pid}.{id wątku}] {komunikat} [{id konta, email_accounts.acntid},{id folderu, email_folders.emfdid}]

Konfiguracja

Możliwa jest zmiana domyślnych wartości parametrów określających częstotliwość wykonywania poszczególnych operacji.

W celu zmiany tych wartości należy ustawić/dodać odpowiednie stałe w pliku public_html/apps/edokumenty/config.inc, a następnie zrestartować sam proces.

Poniżej znajdują się definicje stałych konfiguracyjnych z domyślnymi wartościami.

Maksymalna liczba wątków, jakie mogą zostać uruchomione przez proces główny

define('BG_MAX_THREADS', 14);

Maksymalna liczba zadań skolejkowana w wątku

define('BG_MAX_TASKS_PER_THREAD', 200);

Interwał dla synchronizacji nowych wiadomości dla folderu specjalnego Odebrane oraz folderów oznaczonych wysokim priorytetem dla zalogowanych użytkowników

define('EMAIL_BG_HI_FOLDERS_RECENT_SYNC_INTERVAL', 600);

Interwał dla synchronizacji nowych wiadomości dla folderu specjalnego Odebrane oraz folderów oznaczonych wysokim priorytetem dla niezalogowanych użytkowników

define('EMAIL_BG_HI_FOLDERS_RECENT_SYNC_INTERVAL_NL', 1800);

Interwał dla pełnej synchronizacji dla folderu specjalnego Odebrane oraz folderów oznaczonych wysokim priorytetem dla zalogowanych użytkowników

define('EMAIL_BG_HI_FOLDERS_FOLDERS_FULL_SYNC_INTERVAL', 3600);

Interwał dla pełnej synchronizacji dla folderu specjalnego Odebrane oraz folderów oznaczonych wysokim priorytetem dla niezalogowanych użytkowników

define('EMAIL_BG_HI_FOLDERS_FOLDERS_FULL_SYNC_INTERVAL_NL', 4800);

Czas rozpoczęcia (w formacie HH:MM) codziennej pełnej synchronizacji folderów oznaczonych niskim priorytetem

define('EMAIL_BG_LO_FOLDERS_SYNC_START', '20:00');

Wysyłanie wiadomości oczekujących w folderze Do wysłania wykonywane jest bez dodatkowego czasu oczekiwania. Ponadto zadania wysyłania wiadomości mogą dysponować większą liczbą wątków niż zadania związane z synchronizacją. Fizyczny czas oczekiwania na wysłanie wiadomości zależy więc jedynie od obciążenia serwera oraz liczby zadań aktualnie przetwarzanych przez proces. Zwykle czas ten waha się od kilku sekund do 2-3 minut.

Troubleshooting

Częstym problemem jest brak podłączonego Zenda do CLI (konsolowy PHP) w pliku php.ini w /etc/php5/cli.d/php.ini. Rozwiązaniem jest zmiana nazwy tego pliku na php.old i zlinkowanie pliku z Apache poleceniem:

ln -s /etc/php5/apache2/php.ini /etc/php5/cli.d/

Restart usługi po aktualizacji

Jeśli aktualizacja systemu eDokumenty wykonuje większe zmiany w bazie, zdarza się że proces się zawiesi, co objawia się nieściąganiem poczty automatycznie. W logu - info.log nie pojawiają się komunikaty o pobieraniu.

Należy wówczas zrestartować proces w taki sposób:

1. Edycja /etc/crontab - zahaszować linię odpowiadającą za proces
2. ps aux | grep engine
3. Z wyniku poprzedniego polecenia bierzemy PID (czyli process id - jest w pierwszej kolumnie) i wykonujemy polecenie kill -9 <PID>. Ewentualnie można zamiennie stosować z poleceniem "killall php". To zwykle można bezpiecznie wykonać. chyba że mamy jakieś inne specjalne procesy odpalone na php.
4. z katalogu /home/edokumenty/public_html/apps/backproc/db kasujemy plik 127.0.0.1.db

4a. dla wersji 4.6 - z katalogu /home/edokumenty/public_html/apps/backproc/data kasujemy plik 127.0.0.1.db

5. z katalogu /home/edokumenty/public_html/apps/backproc/pid kasujemy wszystkie pliki
6. Ponowna Edycja /etc/crontab - odhaszować linię odpowiadającą za proces

W efekcie po najdalej 5 minutach powinna ruszyć synchronizacja co możemy obserwować niezmiernie interesującym poleceniem:

tail -f /home/edokumenty/public_html/apps/backproc/logs/20140624-info.log

Ewentualnie możemy sprawdzić również aktywność dla pojedynczego konta poleceniem, gdzie 20150327-info.log to nazwa loga z bieżącego dnia a 99, to klucz główny (acntid) konta które nas interesuje. Numer konta możemy poznać po kliknieciu w pytajnik w dialogu konfiguracji konta.

cat 20150327-info.log | grep 99,