VPS-ல் n8n தொடர்ந்து offline ஆகிறதா? காரணம் கண்டறியுங்கள்

n8n ஏன் தொடர்ந்து offline ஆகிறது: நான்கு failure-கள், ஒரே அறிகுறி

“n8n தொடர்ந்து offline ஆகிறது” என்பது நான்கு வேறுபட்ட failure-களை குறிக்கும் ஒரே வாக்கியம். ஒவ்வொன்றுக்கும் வேறுபட்ட தீர்வு தேவை. Container இயல்பாக இயங்கிக்கொண்டிருந்தாலும், editor-ல் connection lost banner தோன்றலாம். Container தானாகவே restart ஆகலாம். அதிக memory பயன்படுத்துவதால் kernel, Node.js process-ஐ நிறுத்தலாம். அல்லது process-ல் எந்தப் பிரச்சினையும் இல்லாமல், active workflow ஒருபோதும் trigger ஆகாமல் இருக்கலாம். தவறான setting-ஐ மாற்றினால், உங்களிடம் இல்லாத ஒரு பிரச்சினையைத் தீர்க்க முழு வார இறுதியையும் செலவிட நேரிடும்.

எந்த configuration-ஐ மாற்றுவதற்கு முன், உங்களிடம் ஏற்பட்ட failure எது என்பதை கண்டறியவும். n8n ஒரே Node.js process-ஆக இயங்கும். பொதுவாக அது TLS (transport layer security)-ஐ terminate செய்யும் reverse proxy-க்கு பின்னால், ஒரே Docker container-க்குள் இயங்கும். இந்த layers ஒவ்வொன்றும் தனித்தனி முறையில் failure அடையும். ஆனால் browser இவை அனைத்தையும் ஒரே message மூலம் தெரிவிக்கும்.

இந்த வரிசையில் கண்டறியவும்

VPS (virtual private server)-ல் இந்த commands-ஐ இயக்கி, உங்கள் சொந்த machine காட்டும் values-ஐப் படிக்கவும். Forum thread-ல் உள்ள numbers-உடன் அவற்றை ஒப்பிட வேண்டாம். இங்கு முக்கியமான values உங்கள் box-ஐச் சார்ந்தவை; வேறு ஒருவருடைய box-ஐச் சார்ந்தவை அல்ல.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

docker ps -a-ன் STATUS column, container தற்போதைய state-ல் எவ்வளவு நேரமாக உள்ளது என்பதைக் காட்டுகிறது. உங்கள் problem தொடங்கிய நேரத்துடன் அதை ஒப்பிடவும். Banner தோன்றுவதற்கு முன்பே container இயங்கிக் கொண்டிருந்தால், n8n ஒருபோதும் offline ஆகவில்லை. Browser மற்றும் backend இடையிலான connection தான் பாதிக்கப்பட்டுள்ளது. இது அடுத்த section-ல் விளக்கப்படும் websocket path ஆகும்.

RestartCount, Docker இந்த container-ஐ எத்தனை முறை restart செய்துள்ளது என்பதைக் காட்டுகிறது. அந்த number-ஐ எழுதிக் கொண்டு, ஒரு நிமிடம் காத்திருந்து, மீண்டும் அதைச் சரிபார்க்கவும். நீங்கள் கவனித்துக் கொண்டிருக்கும்போது number அதிகரித்தால், அது restart loop ஆகும். ஒவ்வொரு restart-க்கும் முன் உள்ள log lines காரணத்தைத் தெரிவிக்கும்.

OOMKilled, true அல்லது false flag ஆகும். True என்றால், memory limit-ஐ மீறியதால் Linux kernel process-ஐ kill செய்துள்ளது என்று பொருள். அந்த limit container-ன் சொந்த limit ஆகவோ, முழு machine-ன் limit ஆகவோ இருக்கலாம். இந்த field மட்டும் memory kill-ஐ பிற வகையான exits-இலிருந்து வேறுபடுத்திக் காட்டும். அதனால் ஊகிப்பதற்கு முன் இதைப் படிக்க வேண்டும்.

ExitCode, container கடைசியாக exit செய்தபோது பயன்படுத்திய value-ஐக் காட்டுகிறது. ஒவ்வொரு code-ன் பொருளையும் மனப்பாடம் செய்யத் தேவையில்லை. உங்கள் value-ஐப் படித்து, அதே timestamp-இல் உள்ள docker logs-ன் முடிவையும் படிக்கவும். Log tail மற்றும் out of memory flag இரண்டையும் சேர்த்து பார்த்தால்தான் என்ன நடந்தது என்பதைத் தெரிந்துகொள்ள முடியும். அவற்றில் ஒன்றை மட்டும் பார்த்தால் தவறாகப் புரிந்துகொள்ளலாம்.

docker stats, நடைமுறையில் பயன்படுத்தப்படும் memory-ஐ அமலில் உள்ள limit-க்கு அருகில் காட்டுகிறது. இதை இரண்டாவது terminal-ல் இயங்க விட்டுவிட்டு, சிக்கலை ஏற்படுத்தும் workflow-ஐத் தொடங்கவும். Failure நிகழும் நேரத்தில் number எவ்வாறு மாறுகிறது என்பதைக் கவனிக்கவும்.

Connection lost banner பொதுவாக உங்கள் reverse proxy காரணமாகும்

n8n editor, execution progress-ஐ canvas-ல் stream செய்ய backend-க்கு ஒரு நீண்டகால push connection-ஐ திறந்து வைத்திருக்கும். இயல்பாக அந்த connection ஒரு WebSocket ஆகும். இதையே N8N_PUSH_BACKEND தேர்ந்தெடுக்கிறது; அதன் இயல்புநிலை மதிப்பு websocket ஆகும். WebSocket முதலில் Connection: Upgrade மற்றும் Upgrade: websocket headers-ஐ கொண்ட சாதாரண HTTP request ஆகத் தொடங்குகிறது. Server, 101 Switching Protocols எனப் பதிலளிக்கும். அதன் பிறகு இரு பக்கங்களும் ஒரே TCP socket-ஐ இரு திசைகளிலும் பயன்படுத்துகின்றன.

இதைக் கெடுக்கும் இரண்டு காரணங்கள் உள்ளன. அவை இரண்டும் n8n-ல் அல்ல, proxy-ல் உள்ளன. Proxy, upstream-க்கு HTTP/1.0 பயன்படுத்தலாம் அல்லது upgrade headers-ஐ நீக்கலாம். இதனால் upgrade நடைபெறாது; editor தொடர்ந்து reconnect செய்யும். அல்லது upgrade வெற்றிகரமாக நடந்த பிறகு, socket அமைதியாக இருப்பதால் proxy அதை மூடலாம். Messages இல்லாத WebSocket, idle connection போலவே தோன்றும். இரண்டு நிலைகளிலும் container ஆரோக்கியமாகவே இருக்கும். இந்த banner, browser தனது channel-ஐ இழந்துவிட்டதாகச் சொல்கிறது.

எதையும் மாற்றுவதற்கு முன் browser-ல் இதை உறுதிப்படுத்தவும். Developer tools-ஐத் திறந்து, Network tab-க்குச் சென்று, WS-க்கு filter செய்து, editor-ஐ reload செய்யவும். Push request 101 Switching Protocols-ஐ அடைந்து open நிலையில் நீடிக்க வேண்டும். சாதாரண status code-ஐத் திருப்பி அனுப்பும் push request அல்லது சில விநாடிகளுக்கு ஒருமுறை மீண்டும் தோன்றும் request, பிரச்சினை proxy-ல் இருப்பதைக் காட்டுகிறது.

editor இணைப்பை நிலைத்திருக்கச் செய்யும் nginx settings

நீங்கள் குறிப்பாகச் சொல்லாவிட்டால், nginx upgrade request-ஐ forward செய்யாது. proxy_pass backend-உடன் இயல்பாக HTTP/1.0 மூலம் தொடர்புகொள்கிறது. Connection மற்றும் Upgrade hop-by-hop headers என்பதால், nginx அவற்றை வழியில் நீக்கிவிடும். அவை இரண்டையும் மீண்டும் சேர்க்க வேண்டும். map block, http context-ல் இருக்க வேண்டும்; server-க்குள் இருக்கக்கூடாது. கீழே உள்ள server block-ன் மீதிப் பகுதி புரியவில்லை என்றால், nginx server block-ன் ஒவ்வொரு வரிக்குமான விளக்கம் ஒவ்வொரு directive என்ன செய்கிறது என்பதை விளக்குகிறது.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout என்பது பலர் விடுபடும் line ஆகும். இதன் default மதிப்பு 60 seconds. இது upgraded WebSocket-க்கும் பொருந்தும். எனவே அமைதியாக இருக்கும் instance-ல் திறந்து வைக்கப்பட்ட editor tab, கடைசி message கடந்து சென்ற சுமார் ஒரு நிமிடத்துக்குப் பிறகு connection-ஐ இழக்கும். இதன் மதிப்பை உயர்த்தினால், நீண்ட நேரம் திறந்து வைக்கப்பட்ட tab-க்கு திரும்பும்போது காணப்படும் banner பிரச்சினை தீரும்.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T ஒரு file-ஐ மட்டும் அல்லாமல், தற்போது இயங்கும் முழு configuration-ஐ வெளியிடுகிறது. எனவே நீங்கள் செய்த edit உண்மையில் load ஆகியுள்ளதா என்பதை இது உறுதிப்படுத்துகிறது. எந்த include line-உம் எடுத்துக்கொள்ளாத file-ல் configuration இருந்தால், சரியான fix செய்தும் எந்த மாற்றமும் தெரியாததற்கான காரணம் அதுவாகும்.

அதன் பிறகு, n8n proxy-க்கு பின்னால் இயங்குகிறது என்பதை அதற்குத் தெரிவிக்க வேண்டும். ஏனெனில் n8n இந்த values-ஐப் பயன்படுத்தி URLs-ஐ உருவாக்குகிறது.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS-ன் default மதிப்பு 0. இதனால் n8n, connection-ஐ உருவாக்கும் address-ஐ client address எனக் கருதுகிறது; X-Forwarded-For-ஐ புறக்கணிக்கிறது. container-க்கு முன்னால் உள்ள proxies-ன் எண்ணிக்கைக்கு இதை அமைக்கவும். August 2026 நிலவரப்படி, N8N_WEBHOOK_URL தற்போதைய பெயராகும். பழைய WEBHOOK_URL இன்னும் செயல்படும்; ஆனால் startup நேரத்தில் deprecation warning-ஐ வெளியிடும்.

Traefik WebSocket connections-ஐ forward செய்கிறது; பின்னர் timeout செய்கிறது

Traefik, middleware அல்லது கூடுதல் labels எதுவும் இல்லாமலேயே WebSocket upgrade-ஐ forward செய்கிறது. எனவே இந்த banner-ஐ காணும் Traefik user பொதுவாக missing header பிரச்சினையை அல்ல, timeout-ஐ எதிர்கொள்கிறார். இதற்கான settings entryPoint-ல் உள்ளன. August 2026 நிலவரப்படி Traefik v3-ல், idleTimeout-ன் default 180 seconds; readTimeout-ன் default 60 seconds.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy, reverse_proxy-ல் upgrade-ஐ தானாக கையாளுகிறது; அதற்காக எந்த directive-உம் தேவையில்லை. Proxy-ஐ மாற்ற முடியாத நிலையில், அதை வேறு ஒருவர் நிர்வகிப்பதால், N8N_PUSH_BACKEND=sse மூலம் push channel-ஐ மாற்றவும். SSE (server-sent events) என்பது திறந்த நிலையில் வைத்திருக்கும் சாதாரண HTTP response ஆகும். எனவே upgrade-ஐ நிராகரிக்கும் proxy வழியாகவும் அது தொடர்ந்து இயங்கும். ஆனால் மிகவும் குறுகிய idle timeout இருந்தால் connection துண்டிக்கப்படும். Proxy-ஐத் தேர்வு செய்வது தனியான முடிவு. nginx, Caddy மற்றும் Traefik ஒப்பீடு ஒவ்வொன்றையும் இயக்குவதற்கான செலவை விளக்குகிறது.

Container உண்மையாகவே restart ஆகும்போது

RestartCount அதிகரித்தால், container-ல் பிழை ஏற்பட்டு அதை Docker மீண்டும் இயக்குகிறது. ஒவ்வொரு restart-க்கும் முன் log-ல் வந்த timestamp-களை ஒப்பிட்டு, அதற்கு உடனடியாக முன் என்ன நடந்தது என்பதைப் படிக்கவும். கிட்டத்தட்ட அனைத்து நிகழ்வுகளும் நான்கு காரணங்களுக்குள் அடங்கும்: startup-ஐ நிறுத்தும் configuration error, n8n அணுக முடியாத database, இயங்கத் தொடங்கிய பிறகு ஏற்படும் crash, மற்றும் memory kill.

முதலில் volume-ஐச் சரிபார்க்கவும். ஏனெனில் permissions பெரும்பாலும் அமைதியாகப் பிரச்சினையை ஏற்படுத்தும். Official image, unprivileged user node ஆக இயங்கி, அதன் data-வை /home/node/.n8n-ல் சேமிக்கிறது. root உருவாக்கிய bind mount-ஐ அந்த user எழுத முடியாது. எனவே process ஒவ்வொரு முறையும் startup நேரத்தில் முடிவடையும்; restart policy இதை தொடர்ச்சியான loop-க்குள் மறைத்துவிடும்.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

Named volume இந்தப் பிரச்சினையை முழுமையாகத் தவிர்க்கிறது. Docker அதை சரியான ownership-உடன் உருவாக்கும். Bind mount தேவைப்பட்டால், முதல் command காட்டிய numeric user id-க்கு host directory-ஐ chown செய்யவும். Host மற்றும் container இடையிலான ownership mapping-ஐ ஒருமுறை புரிந்துகொள்வது பயனுள்ளதாகும். இந்த image-கள் files-ஐ எழுதும் user-ஐ எவ்வாறு தீர்மானிக்கின்றன என்பதை PUID மற்றும் PGID விளக்கம் விளக்குகிறது.

out of memory காரணமாக ஏற்படும் kill, crash போலத் தோன்றும்

n8n process-க்கு மேலாக இரண்டு தனித்தனி memory ceilings உள்ளன. அவை வெவ்வேறு விதமாக செயலிழக்கும். Container control group limit-ஐ kernel அமல்படுத்துகிறது. அந்த வரம்பை மீறினால், எதையும் எழுதுவதற்கான வாய்ப்பு இல்லாமல் process உடனடியாக kill செய்யப்படும்; OOMKilled true எனக் காட்டும். V8 heap limit-ஐ Node.js-க்குள் அமல்படுத்துகிறது. அந்த வரம்பை மீறினால், Node stack trace உடன் heap error-ஐ ஏற்படுத்தி, தானாகவே வெளியேறும்; எனவே OOMKilled false எனக் காட்டும். Browser-ல் இவை இரண்டும் ஒரே மாதிரியாகத் தோன்றும். docker inspect-ல் பார்த்தால், அவை ஒரு field மட்டுமே வித்தியாசப்படும்.

Node heap ceiling-ஐ container limit-க்கு கீழே அமைக்கவும். Heap ceiling இரண்டில் உயர்ந்ததாக இருந்தால், kernel செயல்படும் இடத்தைக் கடந்தும் V8 allocation-ஐ தொடரும். இதனால் அதன் garbage collector தன் சொந்த வரம்பை அடையாது. இறுதியில், படிக்க log எதுவும் இல்லாத கடுமையான failure மட்டுமே ஏற்படும்.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

உங்கள் VPS-ல் உண்மையில் உள்ள memory-ஐ அடிப்படையாகக் கொண்டு இரண்டு எண்களையும் தேர்ந்தெடுக்கவும். Database, proxy மற்றும் operating system-க்கு போதிய memory-ஐ மீதமாக விடவும். docker stats --no-stream தற்போதைய use-ஐ நடைமுறையில் உள்ள limit-க்கு அருகில் காட்டும். நீங்கள் எழுதிய limit-ஐ Docker உண்மையில் apply செய்துள்ளதா என்பதை இதன் மூலம் சரிபார்க்கலாம். Compose memory limits எவ்வாறு apply செய்யப்படுகின்றன பல limits அமைக்கப்பட்டிருக்கும்போது எந்த key முன்னுரிமை பெறுகிறது என்பதை விளக்குகிறது.

உங்கள் கீழ் குவியும் execution data

ஒரு run நடைபெறும் போது, ஒவ்வொரு node-ன் output-ஐ ஒரு execution வைத்திருக்கும். பின்னர் n8n அந்த data-ஐ சேமிக்கும். இதனால் இரண்டு விளைவுகள் ஏற்படும். ஒரு run-ன் peak memory, அதில் ஒரே நேரத்தில் செலுத்தப்படும் மிகப்பெரிய data batch-ஆல் நிர்ணயிக்கப்படுகிறது. எனவே, ஒரே நேரத்தில் பத்தாயிரம் rows-ஐ கையாளும் workflow, ஒவ்வொரு முறையும் இருநூறு rows-ஐ கையாளும் அதே workflow-விலிருந்து வேறுபட்ட program ஆகும். மேலும், ஏதாவது அதை delete செய்யும் வரை, சேமிக்கப்பட்ட copy தொடர்ந்து பெரிதாகும்.

Pruning இரண்டாவது பிரச்சினையை கையாளுகிறது. August 2026 நிலவரப்படி, pruning enabled நிலையில் உள்ளது; EXECUTIONS_DATA_MAX_AGE 336 hours (14 days) ஆகவும், EXECUTIONS_DATA_PRUNE_MAX_COUNT 10000 ஆகவும் அமைக்கப்பட்டுள்ளது. SQLite இயக்கும் சிறிய VPS-க்கு இவை அதிகமான வரம்புகள். அங்கு அனைத்தையும் ஒரே file வைத்திருக்கும். Editor-ஐ வழங்கும் அதே process அந்த file-ஐ read மற்றும் write செய்ய வேண்டும்.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none என்பது aggressive setting ஆகும். இது debugging-க்காக failed executions-ஐ வைத்திருக்கும்; successful executions-ஐ நீக்கிவிடும். இதை திட்டமிட்டு முடிவு செய்ய வேண்டும். ஏனெனில், error எழுப்பாமல் தவறான output-ஐ உருவாக்கிய workflow பின்னர் ஆய்வு செய்ய எந்தத் தரவையும் விட்டுச் செல்லாது. Pruning முதலில் rows-ஐ deleted எனக் குறிக்கும்; பின்னர் வரும் pass-ல் அவற்றை நீக்கும். SQLite விடுவிக்கப்பட்ட pages-ஐ மீண்டும் பயன்படுத்தும்; அவற்றை disk-க்கு திருப்பி அளிக்காது. எனவே, setting-ஐ மாற்றிய உடனே disk-ல் உள்ள file அளவு குறையாது.

சேமிக்கப்பட்ட மொத்த அளவை அல்லாமல் peak அளவைக் குறைக்க, ஒவ்வொரு run-லும் குறைந்த data-ஐ நகர்த்தவும். பெரிய jobs-ஐ சிறிய results-ஐ parent-க்கு திருப்பி அனுப்பும் sub-workflows ஆகப் பிரிக்கவும். Loop Over Items node மூலம் data-ஐ batch செய்யவும். முழு datasets-ஐ Code node-க்கு வெளியே வைத்திருக்கவும்.

Binary files should not travel through memory

N8N_DEFAULT_BINARY_DATA_MODE-ன் இயல்புநிலை மதிப்பு default ஆகும். இதனால் binary data இயங்கும் execution-ன் memory-ல் சேமிக்கப்படும். ஒரு node download செய்யும் ஒவ்வொரு file-உம், அடுத்த node-க்கு வழங்கப்படும் ஒவ்வொரு copy-உம் run முடியும் வரை memory-ல் இருக்கும். சில பெரிய attachments-ஐ பெறும் ஒரு workflow, வழக்கமான JSON பணிகளில் ஏற்படாத அளவுக்கு process memory limit-ஐ மீறச் செய்யலாம். அதனால் crash குறிப்பிட்ட ஒரு workflow-ஐத் தொடர்ந்து ஏற்படுகிறது; குறிப்பிட்ட நேர இடைவெளியைத் தொடர்ந்து அல்ல.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

filesystem-ஐ பயன்படுத்தும்போது, binary data N8N_BINARY_DATA_STORAGE_PATH-ன் கீழ் எழுதப்படும். இது இயல்பாக n8n user folder-க்குள் இருக்கும். எனவே, மற்ற data இருக்கும் அதே volume-ல் இது சேமிக்கப்படும். இதை மாற்றுவதற்கு முன் volume-ல் போதுமான இடம் உள்ளதா என்பதைச் சரிபார்க்கவும். N8N_PAYLOAD_SIZE_MAX, incoming webhook payload-ன் அதிகபட்ச அளவை MiB (mebibytes) ஆக அமைக்கிறது. இதன் இயல்புநிலை மதிப்பு 16. இதை அதிகரித்தால் பெரிய requests அனுமதிக்கப்படும்; அதற்கான memory செலவை நீங்கள் ஏற்றுக்கொள்கிறீர்கள்.

Server-ல் உள்ள மற்ற அனைத்தும் அதே RAM-ஐப் பயன்படுத்தப் போட்டியிடும். Database container-ஐச் சேர்த்த பிறகே OOM kills தொடங்கியிருந்தால், database-ஐ Docker-ல் அல்லது host-ல் இயக்குவது இப்போது நீங்கள் தேர்வு செய்யும் trade-off ஆகும்.

Restart policy மற்றும் reboot பிறகு மீண்டும் தொடங்குதல்

Restart policy இல்லாத container, exit ஆன பிறகும் host reboot ஆன பிறகும் stopped நிலையில் இருக்கும். restart: unless-stopped இந்த இரண்டு சூழ்நிலைகளிலும் அதை மீண்டும் தொடங்கும்; நீங்கள் கையால் stop செய்த container-ஐ மதிக்கும் வகையிலும் இது செயல்படும். restart: always-ஐ பயன்படுத்தினால், நீங்கள் திட்டமிட்டு stop செய்த container-மும் Docker அடுத்த முறை தொடங்கும்போது மீண்டும் தொடங்கும்.

n8n ஒரு health endpoint-ஐ வழங்குகிறது. அதன் பெயரை N8N_ENDPOINT_HEALTH குறிப்பிடுகிறது; அதன் default value healthz ஆகும். உங்கள் instance-ல் path சரியாக உள்ளதா என்பதை உறுதிப்படுத்த, முதலில் host-லிருந்து அதைச் சரிபார்க்கவும்.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

Healthcheck மட்டும் இருந்தால் எந்த container-மும் தானாக restart ஆகாது. Compose container-ஐ unhealthy என்று குறியிட்டு அங்கேயே நிற்கும். எனவே healthcheck செயல்பட, அதனுடன் restart policy அல்லது வெளிப்புற watcher தேவை. உண்மையில் செயல்படும் healthcheck எழுதுதல் மற்றும் reboot பிறகு stack-ஐ மீண்டும் தொடங்கச் செய்தல் ஆகியவை இந்த இரண்டு பகுதிகளையும் விளக்குகின்றன.

n8n இயங்கிக் கொண்டிருந்தும் workflow ஒருபோதும் இயக்கப்படாத நிலை

இந்த நிலையில் banner அல்லது restart எதுவும் தோன்றாது. container இயங்கிக் கொண்டிருக்கும்; editor செயல்படும்; நீங்கள் எதிர்பார்த்த run executions பட்டியலில் இருக்காது. பெரும்பாலான சந்தர்ப்பங்களில் இதற்கு நான்கு காரணங்கள் உள்ளன.

• workflow active நிலையில் இல்லை. Schedule Trigger production path-ல் மட்டுமே இயங்கும். ஆகவே canvas-ல் அதைச் சோதிப்பதால் schedule உருவாகாது.
• timezone உங்கள் timezone அல்ல. GENERIC_TIMEZONE இயல்பாக America/New_York-க்கு அமைக்கப்பட்டுள்ளது. எனவே GENERIC_TIMEZONE மற்றும் TZ-ஐ உங்கள் timezone-க்கு அமைக்கும் வரை, 09:00-க்கு அமைக்கப்பட்ட schedule அந்த timezone-ன் 09:00 மணிக்கே இயங்கும்.
• downtime-க்குப் பிறகு தவறிய run-கள் ஈடுசெய்யப்படாது. n8n தொடங்கும்போது triggers பதிவு செய்யப்படுகின்றன. ஆகவே container restart ஆகிக் கொண்டிருந்தபோது due ஆன schedule தாமதமாக இயங்காது. startup-க்குப் பிறகு வரவிருக்கும் அடுத்த due time-ல் மட்டுமே அது இயங்கும்.
• workflow உங்களுக்காக deactivated செய்யப்பட்டிருக்கலாம். N8N_WORKFLOW_AUTODEACTIVATION_ENABLED இயல்பாக off நிலையில் இருக்கும். அது on நிலையில் இருந்தால், தொடர்ந்து crash ஆகும் workflow unpublished செய்யப்படும். அதன் பிறகு, அதை யாரும் ஒருபோதும் activate செய்யாதது போலவே தோன்றும்.

executions பட்டியலைத் திறந்து, அந்த workflow-க்கு filter செய்யவும். தோல்வியடைந்த entry இருந்தால் அது workflow பிரச்சினை. அதே server-ல் நீங்கள் host செய்யும் மற்றொரு service-க்கு எதிரான request 429 status-உடன் தோல்வியடைந்திருந்தால், அந்த limit n8n-க்குச் சொந்தமானது அல்ல; அது அந்த service-க்குச் சொந்தமானது. SearXNG 429 வழிகாட்டி அதன் சொந்த rate limiter-ஐ உங்கள் server IP-ஐ block செய்யும் engines-இலிருந்து எவ்வாறு வேறுபடுத்துவது என்பதை விளக்குகிறது. Entry எதுவும் இல்லையெனில் அது trigger பிரச்சினை. மேலே கூறிய நான்கு காரணங்களில்தான் முதலில் தேட வேண்டும்.

முதலில் மாற்ற வேண்டியவை

1. எந்த file-ஐயும் edit செய்வதற்கு முன், உங்கள் சொந்த container-ல் STATUS, RestartCount மற்றும் OOMKilled ஆகியவற்றைப் படிக்கவும்.
2. container ஒருபோதும் நிறுத்தப்படவில்லை என்றால், proxy upgrade headers மற்றும் idle timeout-ஐ சரிசெய்யவும்.
3. OOMKilled உண்மையாக இருந்தால், நீங்கள் திட்டமிட்டு தேர்ந்தெடுத்த container limit-ஐ அமைக்கவும். Node heap ceiling-ஐ அந்த வரம்புக்குக் கீழே வைக்கவும். Binary data-ஐ filesystem-க்கு மாற்றவும்.
4. எதுவும் trigger ஆகவில்லை என்றால், workflow active நிலையில் உள்ளதா என்பதையும் instance timezone உங்கள் timezone-ஆக உள்ளதா என்பதையும் சரிபார்க்கவும்.

இவற்றில் பெரும்பாலானவை, இயங்கும் install-ன் மேல் ஒருமுறை அமைத்து மறந்துவிடக்கூடிய configuration ஆகும். அந்த install-ஐ இன்னும் உருவாக்கிக் கொண்டிருந்தால், HTTPS உடன் Docker-ல் n8n அமைப்பதற்கான வழிகாட்டி-யில்தான் இந்த settings அடிப்படை பெறுகின்றன.

FAQ

n8n container இயங்கிக்கொண்டிருக்கும்போது editor-ல் connection lost banner ஏன் காட்டப்படுகிறது?

Execution progress-ஐ stream செய்ய editor ஒரு WebSocket connection-ஐ திறந்த நிலையில் வைத்திருக்கும். Reverse proxy Connection: Upgrade மற்றும் Upgrade: websocket headers-ஐ forward செய்யவில்லை என்றாலோ, upstream-க்கு HTTP/1.1 பயன்படுத்தவில்லை என்றாலோ, upgrade நிறைவு பெறாது. அப்போது n8n இயல்பாக இயங்கிக்கொண்டிருந்தாலும் browser தொடர்ந்து reconnect செய்யும். nginx-ல் proxy_http_version 1.1 உடன் proxy_set_header ஆகிய இரு lines-ஐயும் சேர்க்க வேண்டும். Quiet tab துண்டிக்கப்படாமல் இருக்க, default 60 seconds-ஐ விட நீளமான proxy_read_timeout ஒன்றையும் அமைக்க வேண்டும். நீங்கள் திருத்திய file-ஐ அல்ல, இயங்கும் configuration-ஐ sudo nginx -T மூலம் சரிபார்க்கவும்.

Out of memory kill-ஐ சாதாரண crash-இலிருந்து எவ்வாறு வேறுபடுத்துவது?

docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount'-ஐ இயக்கி OOMKilled flag-ஐப் பார்க்கவும். அதன் மதிப்பு True என்றால், memory limit-ஐ மீறியதால் kernel process-ஐ நிறுத்தியுள்ளது. Process log எழுதுவதற்கான வாய்ப்பு பெறாததால் container log-ல் பயனுள்ள தகவல் எதுவும் இருக்காது. docker logs-ன் முடிவில் heap error மற்றும் stack trace உடன் False இருந்தால், Node.js தனது V8 heap ceiling-ஐ எட்டியதால் தானாகவே வெளியேறியுள்ளது. NODE_OPTIONS=--max-old-space-size-ஐ உங்கள் container limit-க்குக் கீழே அமைக்கவும். இதனால் இரண்டாவது வகை failure ஏற்படும்; அதில்தான் ஆதாரம் கிடைக்கும்.

Execution data-ஐ prune செய்தால் disk space உடனடியாக விடுவிக்கப்படுமா?

இல்லை. EXECUTIONS_DATA_PRUNE பழைய executions-ஐ deletion-க்காகக் குறிக்கிறது. பின்னர், EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL அமைத்த schedule-ன் அடிப்படையில் அவை நீக்கப்படும். SQLite பயன்படுத்தும்போது, விடுவிக்கப்பட்ட pages-ஐ filesystem-க்கு திருப்பி அளிப்பதற்குப் பதிலாக file அவற்றை மீண்டும் பயன்படுத்தும். எனவே rows நீக்கப்பட்ட பிறகும் disk-ல் காணப்படும் size சில காலம் மாறாமல் இருக்கும். EXECUTIONS_DATA_MAX_AGE மற்றும் EXECUTIONS_DATA_PRUNE_MAX_COUNT ஆகியவற்றை உங்கள் server-க்கு ஏற்ற values-ஆக அமைக்கவும். உடனடியாக அல்லாமல், அடுத்த நாள் மீண்டும் சரிபார்க்கவும்.

n8n restart ஆகிக்கொண்டிருந்தபோது scheduled workflow ஏன் இயங்கவில்லை?

Process தொடங்கும்போது n8n triggers-ஐ register செய்கிறது. n8n நிறுத்தப்பட்டிருந்த காலத்தில் due ஆன schedules-ஐ அது மீண்டும் இயக்காது. எனவே restart loop ஏற்பட்டால் catch-up runs தொடர்ச்சியாக இயங்காது; அதற்கு பதிலாக எந்த execution-மும் இல்லாத நிலை காணப்படும். Startup-க்கு பிறகு due ஆகும் அடுத்த நேரத்தில்தான் அடுத்த execution நடைபெறும். தவறாமல் runs தேவைப்பட்டால், webhook-ஐ அழைக்கும் external caller மூலம் workflow-ஐ இயக்கவும். அப்போது retry logic n8n-க்கு வெளியே இருக்கும்.

n8n பதிலளிப்பதை நிறுத்தினால் healthcheck அதை restart செய்யுமா?

தானாகச் செய்யாது. Compose healthcheck container-ஐ healthy அல்லது unhealthy என்று மட்டுமே குறிக்கும். Restart செய்வது restart policy-ன் பொறுப்பு. எனவே container exit ஆன பிறகு restart: unless-stopped அதை மீண்டும் தொடங்கும். Docker service enabled நிலையில் இருந்தால், host reboot ஆன பிறகும் அது container-ஐ மீண்டும் தொடங்கும். இதை sudo systemctl is-enabled docker மூலம் உறுதிப்படுத்தவும். Unhealthy நிலைக்கு மட்டும் நடவடிக்கை எடுக்க, status-ஐப் படித்து service-ஐ restart செய்யும் Docker-க்கு வெளியிலான watcher தேவை.