N8n in docker accidentally restarting

Describe the issue/error/question

n8n restarting many times at day with errors.

What is the error message (if any)?

node:internal/process/promises:265
            triggerUncaughtException(err, true /* fromPromise */);
            ^
Error: This socket has been ended by the other party
    at Socket.writeAfterFIN [as write] (node:net:474:14)
    at JSStreamSocket.doWrite (node:internal/js_stream_socket:175:19)
    at JSStream.onwrite (node:internal/js_stream_socket:33:57)
    at TLSSocket.Socket._final (node:net:443:28)
    at callFinal (node:internal/streams/writable:694:27)
    at prefinish (node:internal/streams/writable:723:7)
    at finishMaybe (node:internal/streams/writable:733:5)
    at TLSSocket.Writable.end (node:internal/streams/writable:631:5)
    at TLSSocket.Socket.end (node:net:609:31)
    at endWritableNT (node:internal/streams/readable:1372:12)
    at processTicksAndRejections (node:internal/process/task_queues:82:21) {
  code: 'EPIPE',
  source: 'socket'
}

or this

node:internal/process/promises:265
            triggerUncaughtException(err, true /* fromPromise */);
            ^
Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:217:20) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read',
  source: 'socket'
}

Please share the workflow

Dunno which to share. I did not changing any for month. Noticed this errors at 8th march. Updating containers automatically by watchtower.

Share the output returned by the last node

Nope.

Information on your n8n setup

  • n8n version: 0.168.1 (now)
  • Database you’re using (default: SQLite): default
  • Running n8n with the execution process [own(default), main]: main
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: docker

Hi @N8N_userN, I am sorry to hear you’re having trouble with this. I have updated n8n on my server yesterday but didn’t have a restart since:

The ECONNRESET error code would suggest connection problems. Is any of your workflows possibly connecting to a somewhat unreliable service?

I have 3 active workspaces: read IMAP, Telegram(webhook) and Execute Command (bash).
Workflow Executions filtered with errors don’t helps to find problem by time of restart container. Last error was two days ago.

P.S.: mine uptime is 57 minutes for now.

Hi @N8N_userN and @MutedJam

I’ve got a similar error. My self-hosted n8n is restarting every 3-5 minutes. And I also use the EmailReadImap node as a trigger. Actually, the error seems to origin there. This is my log that always looks like this before a restart:

2022-05-16T15:30:33.541Z | debug    | Received child process message of type processHook for execution ID 113026. {"executionId":"113026","file":"WorkflowRunner.js"}
2022-05-16T15:30:33.542Z | debug    | Executing hook (hookFunctionsSave) {"executionId":"113026","workflowId":14,"file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
2022-05-16T15:30:33.543Z | debug    | Save execution data to database for execution ID 113026 {"executionId":"113026","workflowId":14,"finished":true,"stoppedAt":"2022-05-16T15:30:33.539Z","file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
2022-05-16T15:30:33.548Z | debug    | Received child process message of type end for execution ID 113026. {"executionId":"113026","file":"WorkflowRunner.js"}
2022-05-16T15:30:33.552Z | debug    | Executing hook (hookFunctionsPush) {"executionId":"113026","workflowId":14,"file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
2022-05-16T15:31:27.377Z | debug    | Wait tracker querying database for waiting executions {"file":"WaitTracker.js","function":"getwaitingExecutions"}
2022-05-16T15:32:24.589Z | verbose  | IMAP connection was reset - reconnecting. {"file":"EmailReadImap.node.js"}
2022-05-16T15:32:25.755Z | debug    | Querying for new messages on node "EmailReadImap" {"searchCriteria":["UNSEEN",["UID","10661:*"]],"file":"EmailReadImap.node.js","function":"onmail"}
node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^
Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:217:20) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read',
  source: 'socket'
}
2022-05-16T15:32:35.932Z | info     | Initializing n8n process {"file":"start.js"}

Looking into the code, I cannot definitely say at what place the error happens, but it seems like there’s a uncaught promise rejection or something like that.

List of restart event
A B C
1
Event Timestamp WorkflowId
2
Manual execution
2022-05-16T15:53:13.481Z
15
3
Instance started
2022-05-16T16:06:44.003Z
15
4
Instance started
2022-05-16T16:11:08.541Z
15
5
Instance started
2022-05-16T16:15:11.628Z
15
6
Instance started
2022-05-16T16:19:03.928Z
15
7
Instance started
2022-05-16T16:23:00.532Z
15
8
Instance started
2022-05-16T16:27:18.928Z
15
9
Instance started
2022-05-16T16:31:31.122Z
15
10
Instance started
2022-05-16T16:35:47.900Z
15
11
Instance started
2022-05-16T16:39:09.979Z
15
12
Instance started
2022-05-16T16:42:46.407Z
15
13
Instance started
2022-05-16T16:46:29.995Z
15
14
Instance started
2022-05-16T16:50:02.713Z
15
15
Instance started
2022-05-16T16:54:02.402Z
15
16
Instance started
2022-05-16T16:58:05.584Z
15
17
Instance started
2022-05-16T17:01:59.295Z
15
18
Instance started
2022-05-16T17:06:01.578Z
15
19
Instance started
2022-05-16T17:09:54.164Z
15
20
Instance started
2022-05-16T17:13:55.303Z
15
21
Instance started
2022-05-16T17:17:56.457Z
15
22
Instance started
2022-05-16T17:21:51.049Z
15
23
Instance started
2022-05-16T17:25:13.805Z
15
24
Instance started
2022-05-16T17:28:53.648Z
15
25
Instance started
2022-05-16T17:32:49.666Z
15
26
Instance started
2022-05-16T17:36:56.553Z
15
27
Instance started
2022-05-16T17:40:29.223Z
15
28
Instance started
2022-05-16T17:43:53.252Z
15
29
Instance started
2022-05-16T17:47:18.967Z
15
30
Instance started
2022-05-16T17:51:32.594Z
15
31
Instance started
2022-05-16T17:55:37.239Z
15
32
Instance started
2022-05-16T17:59:17.790Z
15
33
Instance started
2022-05-16T18:03:31.816Z
15
34
Instance started
2022-05-16T18:07:08.361Z
15
35
Instance started
2022-05-16T18:11:19.787Z
15
36
Instance started
2022-05-16T18:14:55.229Z
15
37
Instance started
2022-05-16T18:18:51.241Z
15
38
Instance started
2022-05-16T18:22:52.141Z
15
39
Instance started
2022-05-16T18:26:25.269Z
15
40
Instance started
2022-05-16T18:30:07.316Z
15
41
Instance started
2022-05-16T18:33:56.986Z
15

Hi @baflo, are you by any chance using an n8n version older than 0.171.0? This version contains a fix for the IMAP node crashing n8n.

Which IMAP server are you running (or connecting to if you don’t run it yourself)?

Hi @MutedJam, I am running n8n on 0.171.1… the mail server I am connecting to is GMail.

Thanks @baflo, and just to double-check, when you disable your workflow containing the IMAP node, the crashes stop?

I’ve had the workflow disabled for an hour now. While it was disabled, there were no restarts. Aber re-enabling the workflow, it began to restart again:

image|320

1 Like

Hi. I still here :slight_smile:
Version: 0.173.1
IMAP server: imap.yandex.ru

Played around with IMAP node options, but seems no result - container restarting when workflow is active. And yes, it’s receiving mails if active.

1 Like

Thanks for confirming both of you. Tbh, I don’t quite know what might cause this (I did even set up a test imap server on my end and killed it, have it join and leave my network for a few hours today, but n8n just wouldn’t crash) :frowning:

I’ll add this to our bug tracker for a closer look by our engineering team though, hopefully they have some better idea of what might be going on.

Just a wild guess, but I want to share my observation…

I found these lines in [email protected] (notice the comment in L34):

In n8n’s EmailReadImap node you’re calling connection.end() in multiple occasions and also have an error event handling…

…but that’s without the check whether it was ended purposely. Also, I don’t know if it is correct to throw an error, even if the connection was successfully reconnected.

1 Like

I actually think it might origin from here… that is because I do use force reconnect (although it’s set to 60 minutes)

1 Like