[Bug]: Server crash when reaching maximum file watchers #2165

@rpgdev commented on GitHub (Aug 8, 2024):

I'm having the same issue.. I just started using abs a few weeks ago so I only have 21 books on it. If it's because of file watchers then it's quite a coincidence. My primary language is Spanish and this happened without me realizing it at first just finding the container crashed and unable to access it then "matching" authors with Spanish names.

@rpgdev commented on GitHub (Aug 8, 2024): I'm having the same issue.. I just started using abs a few weeks ago so I only have 21 books on it. If it's because of file watchers then it's quite a coincidence. My primary language is Spanish and this happened without me realizing it at first just finding the container crashed and unable to access it then "matching" authors with Spanish names.

adam commented

@rpgdev commented on GitHub (Aug 8, 2024):

This is my crash log:

{"timestamp":"2024-08-08 13:23:54.961","source":"Server.js:171","message":"[Server] Unhandled rejection: SequelizeDatabaseError: SQLITE_CORRUPT: database disk image is malformed, promise: Promise {\n  <rejected> Error\n      at Database.<anonymous> (/node_modules/sequelize/lib/dialects/sqlite/query.js:185:27)\n      at /node_modules/sequelize/lib/dialects/sqlite/query.js:183:50\n      at new Promise (<anonymous>)\n      at Query.run (/node_modules/sequelize/lib/dialects/sqlite/query.js:183:12)\n      at /node_modules/sequelize/lib/sequelize.js:315:28\n      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n      at async SQLiteQueryInterface.bulkUpdate (/node_modules/sequelize/lib/dialects/abstract/query-interface.js:366:12)\n      at async author.update (/node_modules/sequelize/lib/model.js:2010:28)\n      at async ApiRouter.match (/server/controllers/AuthorController.js:325:7) {\n    name: 'SequelizeDatabaseError',\n    parent: [Error: SQLITE_CORRUPT: database disk image is malformed] {\n      errno: 11,\n      code: 'SQLITE_CORRUPT',\n      sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9'\n    },\n    original: [Error: SQLITE_CORRUPT: database disk image is malformed] {\n      errno: 11,\n      code: 'SQLITE_CORRUPT',\n      sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9'\n    },\n    sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9',\n    parameters: {}\n  }\n}","levelName":"FATAL","level":5}

@rpgdev commented on GitHub (Aug 8, 2024): This is my crash log: ```txt {"timestamp":"2024-08-08 13:23:54.961","source":"Server.js:171","message":"[Server] Unhandled rejection: SequelizeDatabaseError: SQLITE_CORRUPT: database disk image is malformed, promise: Promise {\n <rejected> Error\n at Database.<anonymous> (/node_modules/sequelize/lib/dialects/sqlite/query.js:185:27)\n at /node_modules/sequelize/lib/dialects/sqlite/query.js:183:50\n at new Promise (<anonymous>)\n at Query.run (/node_modules/sequelize/lib/dialects/sqlite/query.js:183:12)\n at /node_modules/sequelize/lib/sequelize.js:315:28\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async SQLiteQueryInterface.bulkUpdate (/node_modules/sequelize/lib/dialects/abstract/query-interface.js:366:12)\n at async author.update (/node_modules/sequelize/lib/model.js:2010:28)\n at async ApiRouter.match (/server/controllers/AuthorController.js:325:7) {\n name: 'SequelizeDatabaseError',\n parent: [Error: SQLITE_CORRUPT: database disk image is malformed] {\n errno: 11,\n code: 'SQLITE_CORRUPT',\n sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9'\n },\n original: [Error: SQLITE_CORRUPT: database disk image is malformed] {\n errno: 11,\n code: 'SQLITE_CORRUPT',\n sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9'\n },\n sql: 'UPDATE `authors` SET `id`=$1,`name`=$2,`lastFirst`=$3,`asin`=$4,`description`=$5,`imagePath`=$6,`libraryId`=$7,`updatedAt`=$8 WHERE `id` = $9',\n parameters: {}\n }\n}","levelName":"FATAL","level":5} ```

adam commented

@Scarprovider commented on GitHub (Aug 8, 2024):

Same here, running on a Synology docker for more than 6 months without issue. Today just crashed, no upgrade involve, without any reason and showed Unhealthy status in Portainer. A simple restart and ABS is running great again.

Error text:

[AudioBookShelf] [🔴 Down] Request failed with status code 524

@Scarprovider commented on GitHub (Aug 8, 2024): Same here, running on a Synology docker for more than 6 months without issue. Today just crashed, no upgrade involve, without any reason and showed Unhealthy status in Portainer. A simple restart and ABS is running great again. Error text: [AudioBookShelf] [🔴 Down] Request failed with status code 524

adam commented

@glacasa commented on GitHub (Aug 8, 2024):

Same here !
I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days.
The app just stops responding, nothing loads until I get a timeout. No error in the logs.

I'm also on version v2.12.1

@glacasa commented on GitHub (Aug 8, 2024): Same here ! I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days. The app just stops responding, nothing loads until I get a timeout. No error in the logs. I'm also on version v2.12.1

adam commented

@Vito0912 commented on GitHub (Aug 8, 2024):

Same here ! I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days. The app just stops responding, nothing loads until I get a timeout. No error in the logs.

I'm also on version v2.12.1

Do your CPU spikes during the downtime?

@Vito0912 commented on GitHub (Aug 8, 2024): > Same here ! I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days. The app just stops responding, nothing loads until I get a timeout. No error in the logs. > > I'm also on version v2.12.1 Do your CPU spikes during the downtime?

adam commented

@glacasa commented on GitHub (Aug 8, 2024):

Do your CPU spikes during the downtime?

I can't tell because I don't monitor the server cpu, sorry 😅

But after looking this other issue, it seems I have the same problem : some people noticed ABS crashed after 24 hours, and I can confirm the second crash happened 24 hours after the last restart

@glacasa commented on GitHub (Aug 8, 2024): > Do your CPU spikes during the downtime? I can't tell because I don't monitor the server cpu, sorry 😅 But after looking [this other issue](https://github.com/advplyr/audiobookshelf/issues/3251), it seems I have the same problem : some people noticed ABS crashed after 24 hours, and I can confirm the second crash happened 24 hours after the last restart

adam commented

@MikeGold commented on GitHub (Aug 8, 2024):

For me it was also 2 crashes in the last 48 hours and no issues whatsoever in the past. My CPU does not spike and I never have downtimes as the same NAS is running a quite massive Plex server and about 10 other docker containers. Everything is incredibly stable and never freezes. It's the only docker container that I ever seen crashing. Maybe I'm just lucky...

@MikeGold commented on GitHub (Aug 8, 2024): For me it was also 2 crashes in the last 48 hours and no issues whatsoever in the past. My CPU does not spike and I never have downtimes as the same NAS is running a quite massive Plex server and about 10 other docker containers. Everything is incredibly stable and never freezes. It's the only docker container that I ever seen crashing. Maybe I'm just lucky...

adam commented

@nikolausmoll commented on GitHub (Aug 8, 2024):

Same here... didn't change anything, had to restart ABS yesterday and after about 24h right now again.
Can't remember any ABS crash before.

@nikolausmoll commented on GitHub (Aug 8, 2024): Same here... didn't change anything, had to restart ABS yesterday and after about 24h right now again. Can't remember any ABS crash before.

adam commented

@bloodscript commented on GitHub (Aug 8, 2024):

I today had this issue the second time, approximately 24 Hours After Last occurance. I looked into the Logs and found nothing that made me think that I found the issue. Will provide the Logs tomorrow. Running in Container on Pi for 6 Montag without any issues. Watchtower may have upgraded the Image...

@bloodscript commented on GitHub (Aug 8, 2024): I today had this issue the second time, approximately 24 Hours After Last occurance. I looked into the Logs and found nothing that made me think that I found the issue. Will provide the Logs tomorrow. Running in Container on Pi for 6 Montag without any issues. Watchtower may have upgraded the Image...

adam commented

2026-04-25 00:04:27 +02:00

@rweatherly commented on GitHub (Aug 8, 2024):

same issue here. after the lates update (skipped 2.12.0 went directly to 2.12.1. haven't added any books, and same 2 users using it daily and the container has crashed each day now since the update

@rweatherly commented on GitHub (Aug 8, 2024): same issue here. after the lates update (skipped 2.12.0 went directly to 2.12.1. haven't added any books, and same 2 users using it daily and the container has crashed each day now since the update

adam commented

@ghost commented on GitHub (Aug 9, 2024):

Same here ! I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days. The app just stops responding, nothing loads until I get a timeout. No error in the logs.
I'm also on version v2.12.1

Do your CPU spikes during the downtime?

Mine was at 99% of one cpu, which is how I found that it was not responding. It has crashed twice now.

@ghost commented on GitHub (Aug 9, 2024): > > Same here ! I run audiobookshelf in Docker, in a VPS. No problem for months, and then 2 crashes in the last 2 days. The app just stops responding, nothing loads until I get a timeout. No error in the logs. > > I'm also on version v2.12.1 > > Do your CPU spikes during the downtime? Mine was at 99% of one cpu, which is how I found that it was not responding. It has crashed twice now.

adam commented

2026-04-25 00:04:27 +02:00

@vicerious001 commented on GitHub (Aug 9, 2024):

I think I'm having this issue also since updating to 2.12.1. The container stops responding to web requests almost exactly 24 hours after it was started.

@vicerious001 commented on GitHub (Aug 9, 2024): I think I'm having this issue also since updating to 2.12.1. The container stops responding to web requests almost exactly 24 hours after it was started.

adam commented

2026-04-25 00:04:27 +02:00

@rweatherly commented on GitHub (Aug 9, 2024):

I think I'm having this issue also since updating to 2.12.1. The container stops responding to web requests almost exactly 24 hours after it was started.

im seeing the same thing, it was 24 hours from the restart yesterday till when it crashed again today

@rweatherly commented on GitHub (Aug 9, 2024): > I think I'm having this issue also since updating to 2.12.1. The container stops responding to web requests almost exactly 24 hours after it was started. im seeing the same thing, it was 24 hours from the restart yesterday till when it crashed again today

adam commented

@daneroo commented on GitHub (Aug 9, 2024):

Similar issue, 2 restarts in 2 days. Never happened before 2.12.1.

container is still running, but not responding to web requests
restart fixed it.

(docker compose on ubuntu 22.04)

Would love to help diagnose this; Let us know how to help to resolve this.

@daneroo commented on GitHub (Aug 9, 2024): Similar issue, 2 restarts in 2 days. Never happened before 2.12.1. - container is still running, but not responding to web requests - restart fixed it. (docker compose on ubuntu 22.04) Would love to help diagnose this; Let us know how to help to resolve this.

adam commented

@lyguang90716 commented on GitHub (Aug 9, 2024):

I think I'm having this issue also since updating to 2.12.1

@lyguang90716 commented on GitHub (Aug 9, 2024): I think I'm having this issue also since updating to 2.12.1

adam commented

@nichwall commented on GitHub (Aug 9, 2024):

Release 2.12.2 released earlier today reverted the new Memory store, so the server should not stop responding after 24 hours

@nichwall commented on GitHub (Aug 9, 2024): Release 2.12.2 released earlier today reverted the new Memory store, so the server should not stop responding after 24 hours

adam commented

@AemonCao commented on GitHub (Aug 9, 2024):

After updating to 2.12.2 I can't start the container.

text  error  warn  system  array  login  

    config: {
      transitional: [Object],
      adapter: [Function: httpAdapter],
      transformRequest: [Array],
      transformResponse: [Array],
      timeout: 0,
      xsrfCookieName: 'XSRF-TOKEN',
      xsrfHeaderName: 'X-XSRF-TOKEN',
      maxContentLength: -1,
      maxBodyLength: -1,
      env: [Object],
      validateStatus: [Function: validateStatus],
      headers: [Object],
      method: 'get',
      url: 'https://api.github.com/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1',
      data: undefined
    },
    request: ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 7,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      destroyed: true,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: true,
      maxRequestsOnConnectionReached: false,
      _defaultKeepAlive: true,
      useChunkedEncodingByDefault: false,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      strictContentLength: false,
      _contentLength: 0,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      _closed: true,
      socket: [TLSSocket],
      _header: 'GET /repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1 HTTP/1.1\r\n' +
        'Accept: application/vnd.github.v3+json\r\n' +
        'User-Agent: axios\r\n' +
        'Host: api.github.com\r\n' +
        'Connection: keep-alive\r\n' +
        '\r\n',
      _keepAliveTimeout: 0,
      _onPendingData: [Function: nop],
      agent: [Agent],
      socketPath: undefined,
      method: 'GET',
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      joinDuplicateHeaders: undefined,
      path: '/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1',
      _ended: true,
      res: [IncomingMessage],
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      host: 'api.github.com',
      protocol: 'https:',
      _redirectable: [Writable],
      [Symbol(shapeMode)]: false,
      [Symbol(kCapture)]: false,
      [Symbol(kBytesWritten)]: 0,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype],
      [Symbol(errored)]: null,
      [Symbol(kHighWaterMark)]: 16384,
      [Symbol(kRejectNonStandardBodyWrites)]: false,
      [Symbol(kUniqueHeaders)]: null
    },
    response: {
      status: 403,
      statusText: 'rate limit exceeded',
      headers: [Object],
      config: [Object],
      request: [ClientRequest],
      data: [Object]
    }
  }
} (Server.js:170)

@AemonCao commented on GitHub (Aug 9, 2024): After updating to 2.12.2 I can't start the container. ```log text error warn system array login config: { transitional: [Object], adapter: [Function: httpAdapter], transformRequest: [Array], transformResponse: [Array], timeout: 0, xsrfCookieName: 'XSRF-TOKEN', xsrfHeaderName: 'X-XSRF-TOKEN', maxContentLength: -1, maxBodyLength: -1, env: [Object], validateStatus: [Function: validateStatus], headers: [Object], method: 'get', url: 'https://api.github.com/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1', data: undefined }, request: ClientRequest { _events: [Object: null prototype], _eventsCount: 7, _maxListeners: undefined, outputData: [], outputSize: 0, writable: true, destroyed: true, _last: true, chunkedEncoding: false, shouldKeepAlive: true, maxRequestsOnConnectionReached: false, _defaultKeepAlive: true, useChunkedEncodingByDefault: false, sendDate: false, _removedConnection: false, _removedContLen: false, _removedTE: false, strictContentLength: false, _contentLength: 0, _hasBody: true, _trailer: '', finished: true, _headerSent: true, _closed: true, socket: [TLSSocket], _header: 'GET /repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1 HTTP/1.1\r\n' + 'Accept: application/vnd.github.v3+json\r\n' + 'User-Agent: axios\r\n' + 'Host: api.github.com\r\n' + 'Connection: keep-alive\r\n' + '\r\n', _keepAliveTimeout: 0, _onPendingData: [Function: nop], agent: [Agent], socketPath: undefined, method: 'GET', maxHeaderSize: undefined, insecureHTTPParser: undefined, joinDuplicateHeaders: undefined, path: '/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1', _ended: true, res: [IncomingMessage], aborted: false, timeoutCb: null, upgradeOrConnect: false, parser: null, maxHeadersCount: null, reusedSocket: false, host: 'api.github.com', protocol: 'https:', _redirectable: [Writable], [Symbol(shapeMode)]: false, [Symbol(kCapture)]: false, [Symbol(kBytesWritten)]: 0, [Symbol(kNeedDrain)]: false, [Symbol(corked)]: 0, [Symbol(kOutHeaders)]: [Object: null prototype], [Symbol(errored)]: null, [Symbol(kHighWaterMark)]: 16384, [Symbol(kRejectNonStandardBodyWrites)]: false, [Symbol(kUniqueHeaders)]: null }, response: { status: 403, statusText: 'rate limit exceeded', headers: [Object], config: [Object], request: [ClientRequest], data: [Object] } } } (Server.js:170) ```

adam commented

@olnir commented on GitHub (Aug 9, 2024):

Same here.
Running in docker on Synology.

Had no issues until upgrading to latest version.

@olnir commented on GitHub (Aug 9, 2024): Same here. Running in docker on Synology. Had no issues until upgrading to latest version.

adam commented

@rpgdev commented on GitHub (Aug 9, 2024):

Updated to 2.12.2 and I see no issues on the logs so far 🤞

@rpgdev commented on GitHub (Aug 9, 2024): Updated to 2.12.2 and I see no issues on the logs so far :crossed_fingers:

adam commented

@nikolausmoll commented on GitHub (Aug 9, 2024):

@rpgdev: When did you update to 2.12.2?

@nikolausmoll commented on GitHub (Aug 9, 2024): @rpgdev: When did you update to 2.12.2?

adam commented

@rpgdev commented on GitHub (Aug 9, 2024):

@nikolausmoll just now.

@rpgdev commented on GitHub (Aug 9, 2024): @nikolausmoll just now.

adam commented

@nikolausmoll commented on GitHub (Aug 9, 2024):

okay, it is not about the bug but about what AemonCao wrote?

My ABS is running 2.12.2 since 2024-08-09 06:04:00 (UTC+2 I guess), almost 9 hours, but I care for what happens tonight.

@nikolausmoll commented on GitHub (Aug 9, 2024): okay, it is not about the bug but about what AemonCao wrote? My ABS is running 2.12.2 since 2024-08-09 06:04:00 (UTC+2 I guess), almost 9 hours, but I care for what happens tonight.

adam commented

@SyndicatedPillbug commented on GitHub (Aug 9, 2024):

Glad this isn't just me. I keep getting a "Warning" on my Container Manager in Synology. The container hasn't fully crashed, but it's not responding. This has happened three times in the last four or so days. I have to restart the container. Then it works for a while, but I inevitably have to go back and restart it again.

In the ABS logs I don't see an error, just "WARN Removed 1 sessions that were 3 seconds or less"

@SyndicatedPillbug commented on GitHub (Aug 9, 2024): Glad this isn't just me. I keep getting a "Warning" on my Container Manager in Synology. The container hasn't fully crashed, but it's not responding. This has happened three times in the last four or so days. I have to restart the container. Then it works for a while, but I inevitably have to go back and restart it again. In the ABS logs I don't see an error, just "WARN Removed 1 sessions that were 3 seconds or less"

adam commented

@MikeGold commented on GitHub (Aug 9, 2024):

So I've mentioned yesterday that I've turned off the watchers and my logs were absolutely error free since. Today, about 24 hours since the last restart, my audiobookshelf had a fullblown crash that forced the docker container to restart. Well, that's something different. No crash logs :D.

Should I update to 2.12.2? Some said that it's not starting for them...

@MikeGold commented on GitHub (Aug 9, 2024): So I've mentioned yesterday that I've turned off the watchers and my logs were absolutely error free since. Today, about 24 hours since the last restart, my audiobookshelf had a fullblown crash that forced the docker container to restart. Well, that's something different. No crash logs :D. Should I update to 2.12.2? Some said that it's not starting for them...

adam commented

@AemonCao commented on GitHub (Aug 9, 2024):

After updating to 2.12.2 I can't start the container.更新到 2.12.2 后，我无法启动容器。

text  error  warn  system  array  login  

    config: {
      transitional: [Object],
      adapter: [Function: httpAdapter],
      transformRequest: [Array],
      transformResponse: [Array],
      timeout: 0,
      xsrfCookieName: 'XSRF-TOKEN',
      xsrfHeaderName: 'X-XSRF-TOKEN',
      maxContentLength: -1,
      maxBodyLength: -1,
      env: [Object],
      validateStatus: [Function: validateStatus],
      headers: [Object],
      method: 'get',
      url: 'https://api.github.com/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1',
      data: undefined
    },
    request: ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 7,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      destroyed: true,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: true,
      maxRequestsOnConnectionReached: false,
      _defaultKeepAlive: true,
      useChunkedEncodingByDefault: false,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      strictContentLength: false,
      _contentLength: 0,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      _closed: true,
      socket: [TLSSocket],
      _header: 'GET /repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1 HTTP/1.1\r\n' +
        'Accept: application/vnd.github.v3+json\r\n' +
        'User-Agent: axios\r\n' +
        'Host: api.github.com\r\n' +
        'Connection: keep-alive\r\n' +
        '\r\n',
      _keepAliveTimeout: 0,
      _onPendingData: [Function: nop],
      agent: [Agent],
      socketPath: undefined,
      method: 'GET',
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      joinDuplicateHeaders: undefined,
      path: '/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1',
      _ended: true,
      res: [IncomingMessage],
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      host: 'api.github.com',
      protocol: 'https:',
      _redirectable: [Writable],
      [Symbol(shapeMode)]: false,
      [Symbol(kCapture)]: false,
      [Symbol(kBytesWritten)]: 0,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype],
      [Symbol(errored)]: null,
      [Symbol(kHighWaterMark)]: 16384,
      [Symbol(kRejectNonStandardBodyWrites)]: false,
      [Symbol(kUniqueHeaders)]: null
    },
    response: {
      status: 403,
      statusText: 'rate limit exceeded',
      headers: [Object],
      config: [Object],
      request: [ClientRequest],
      data: [Object]
    }
  }
} (Server.js:170)

Sorry, my reply may be off topic.

After an update, the container suddenly became inaccessible (it could run normally for a while after restart), but it became inaccessible again after a while (usually the next day). So today I updated to the latest version 2.12.2. Then the container became inaccessible.

After that, I had to downgrade to 2.11.0, which is still normal. I don’t know if the original inaccessibility problem will occur again tomorrow.

@AemonCao commented on GitHub (Aug 9, 2024): > After updating to 2.12.2 I can't start the container.更新到 2.12.2 后，我无法启动容器。 > > ``` > text error warn system array login > > config: { > transitional: [Object], > adapter: [Function: httpAdapter], > transformRequest: [Array], > transformResponse: [Array], > timeout: 0, > xsrfCookieName: 'XSRF-TOKEN', > xsrfHeaderName: 'X-XSRF-TOKEN', > maxContentLength: -1, > maxBodyLength: -1, > env: [Object], > validateStatus: [Function: validateStatus], > headers: [Object], > method: 'get', > url: 'https://api.github.com/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1', > data: undefined > }, > request: ClientRequest { > _events: [Object: null prototype], > _eventsCount: 7, > _maxListeners: undefined, > outputData: [], > outputSize: 0, > writable: true, > destroyed: true, > _last: true, > chunkedEncoding: false, > shouldKeepAlive: true, > maxRequestsOnConnectionReached: false, > _defaultKeepAlive: true, > useChunkedEncodingByDefault: false, > sendDate: false, > _removedConnection: false, > _removedContLen: false, > _removedTE: false, > strictContentLength: false, > _contentLength: 0, > _hasBody: true, > _trailer: '', > finished: true, > _headerSent: true, > _closed: true, > socket: [TLSSocket], > _header: 'GET /repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1 HTTP/1.1\r\n' + > 'Accept: application/vnd.github.v3+json\r\n' + > 'User-Agent: axios\r\n' + > 'Host: api.github.com\r\n' + > 'Connection: keep-alive\r\n' + > '\r\n', > _keepAliveTimeout: 0, > _onPendingData: [Function: nop], > agent: [Agent], > socketPath: undefined, > method: 'GET', > maxHeaderSize: undefined, > insecureHTTPParser: undefined, > joinDuplicateHeaders: undefined, > path: '/repos/ffbinaries/ffbinaries-prebuilt/releases/tags/v5.1', > _ended: true, > res: [IncomingMessage], > aborted: false, > timeoutCb: null, > upgradeOrConnect: false, > parser: null, > maxHeadersCount: null, > reusedSocket: false, > host: 'api.github.com', > protocol: 'https:', > _redirectable: [Writable], > [Symbol(shapeMode)]: false, > [Symbol(kCapture)]: false, > [Symbol(kBytesWritten)]: 0, > [Symbol(kNeedDrain)]: false, > [Symbol(corked)]: 0, > [Symbol(kOutHeaders)]: [Object: null prototype], > [Symbol(errored)]: null, > [Symbol(kHighWaterMark)]: 16384, > [Symbol(kRejectNonStandardBodyWrites)]: false, > [Symbol(kUniqueHeaders)]: null > }, > response: { > status: 403, > statusText: 'rate limit exceeded', > headers: [Object], > config: [Object], > request: [ClientRequest], > data: [Object] > } > } > } (Server.js:170) > ``` Sorry, my reply may be off topic. After an update, the container suddenly became inaccessible (it could run normally for a while after restart), but it became inaccessible again after a while (usually the next day). So today I updated to the latest version 2.12.2. Then the container became inaccessible. After that, I had to downgrade to 2.11.0, which is still normal. I don’t know if the original inaccessibility problem will occur again tomorrow.

adam commented

@ghost commented on GitHub (Aug 9, 2024):

Working fine on 2.12.2 here, no crashes, no high cpu

@ghost commented on GitHub (Aug 9, 2024): Working fine on 2.12.2 here, no crashes, no high cpu

adam commented

@SyndicatedPillbug commented on GitHub (Aug 9, 2024):

Container crashed today. Not a weir freeze with a Warning like I saw before, but an actual crash notification. It auto-restarted fine, but...

@SyndicatedPillbug commented on GitHub (Aug 9, 2024): ![image](https://github.com/user-attachments/assets/294d910f-fb1d-481b-a77c-ce84fad19fdd) Container crashed today. Not a weir freeze with a Warning like I saw before, but an actual crash notification. It auto-restarted fine, but...

adam commented

@nikolausmoll commented on GitHub (Aug 9, 2024):

I guess no one here tested 2.12.2 long enough to say that it does not crash after a day... i can tell tomorrow morning, if it crashed.

@nikolausmoll commented on GitHub (Aug 9, 2024): I guess no one here tested 2.12.2 long enough to say that it does not crash after a day... i can tell tomorrow morning, if it crashed.

adam commented

@advplyr commented on GitHub (Aug 9, 2024):

@SyndicatedPillbug that warning isn't related to any crash. Are you able to get the actual crash log?
It would be in /metadata/logs/crash_logs.txt

@advplyr commented on GitHub (Aug 9, 2024): @SyndicatedPillbug that warning isn't related to any crash. Are you able to get the actual crash log? It would be in `/metadata/logs/crash_logs.txt`

adam commented

@SyndicatedPillbug commented on GitHub (Aug 9, 2024):

I don't see any crash_logs file, sadly. :/

@SyndicatedPillbug commented on GitHub (Aug 9, 2024): I don't see any crash_logs file, sadly. :/

adam commented

@advplyr commented on GitHub (Aug 10, 2024):

This issue got derailed into completely separate issues. This is specific to the server crashing when the system cannot assign anymore file watchers.
I will leave this open because we should try to handle this more gracefully and disable the watcher.

Any issues unrelated to file watchers should go in another thread.

@advplyr commented on GitHub (Aug 10, 2024): This issue got derailed into completely separate issues. This is specific to the server crashing when the system cannot assign anymore file watchers. I will leave this open because we should try to handle this more gracefully and disable the watcher. Any issues unrelated to file watchers should go in another thread.

adam commented

@rpgdev commented on GitHub (Aug 10, 2024):

@advplyr roger! I'll unwatch this issue since my issue was different, it just happened to coincide and the title of the bug described my situation (or someone linked it in a different one that was related).

@rpgdev commented on GitHub (Aug 10, 2024): @advplyr roger! I'll unwatch this issue since my issue was different, it just happened to coincide and the title of the bug described my situation (or someone linked it in a different one that was related).

adam commented

@MikeGold commented on GitHub (Aug 10, 2024):

@advplyr It was proven here, that my crashes were not related to the watchers errors, but were some other issue that does not leave trace in logs. Multiple other people had the same issue as I did (with semi crash after 24 hours) and reported it here. If you are planning to limit this bug report to just watchers, can you please point all of us to some new bug post that we can follow for that 24 hours crash? I don't think that anyone care about watchers, but the daily crashes are rather major issue for all of us.

Or maybe alternatively you'd like me to open a new bug?

@MikeGold commented on GitHub (Aug 10, 2024): @advplyr It was proven here, that my crashes were not related to the watchers errors, but were some other issue that does not leave trace in logs. Multiple other people had the same issue as I did (with semi crash after 24 hours) and reported it here. If you are planning to limit this bug report to just watchers, can you please point all of us to some new bug post that we can follow for that 24 hours crash? I don't think that anyone care about watchers, but the daily crashes are rather major issue for all of us. Or maybe alternatively you'd like me to open a new bug?

adam commented

@MikeGold commented on GitHub (Aug 10, 2024):

@nikolausmoll Regardless everything else, please let us know in here tomorrow if the server crashed for you again.

@MikeGold commented on GitHub (Aug 10, 2024): @nikolausmoll Regardless everything else, please let us know in here tomorrow if the server crashed for you again.

adam commented