"You are currently using an old version": Am I, though?

Developer help Installation
1

Reposting from "You are currently using an old version": Am I, though? · Issue #11937 · TryGhost/Ghost · GitHub

My installation is running Ghost 3.22.1, and is telling me that I’m not running the latest version of Ghost. That issue was closed, because apparently it’s not a bug on the backend but is rather a configuration issue on my end.

How can I troubleshoot this issue?

2

The first thing I’d do is look for errors in your logs relating to the update check service.

3

I only have two errors in my log, and they both deal with Ghost trying to connect to the wrong address. In both instances,

For example:

[2020-07-06 12:02:56] ERROR Unknown Request error.

Unknown Request error.

"https://xobs.io/favicon.ico"

Error ID:
    a0a8fd50-bf80-11ea-bacc-b1b081ee424c

Error Code:
    IMAGE_SIZE_URL

----------------------------------------

InternalServerError: Unknown Request error.
    at new InternalServerError (/var/lib/ghost/versions/3.22.1/node_modules/ghost-ignition/lib/errors/index.js:90:23)
    at /var/lib/ghost/versions/3.22.1/core/server/lib/image/image-size.js:176:31
    at tryCatcher (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/promise.js:725:18)
    at _drainQueueStep (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/var/lib/ghost/versions/3.22.1/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:456:21)
    at process.topLevelDomainCallback (domain.js:137:15)

RequestError: connect EHOSTUNREACH 132.147.96.146:443
    at ClientRequest.<anonymous> (/var/lib/ghost/versions/3.22.1/node_modules/got/source/request-as-event-emitter.js:178:14)
    at Object.onceWrapper (events.js:422:26)
    at ClientRequest.emit (events.js:327:22)
    at ClientRequest.EventEmitter.emit (domain.js:482:12)
    at ClientRequest.origin.emit (/var/lib/ghost/versions/3.22.1/node_modules/@szmarczak/http-timer/source/index.js:37:11)
    at TLSSocket.socketErrorListener (_http_client.js:426:9)
    at TLSSocket.emit (events.js:315:20)
    at TLSSocket.EventEmitter.emit (domain.js:482:12)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:84:21)

I’ve fixed this (which also fixed an issue with timed posts not going out, so thank you for having me look at it!), but it did not fix the banner.

For anyone else who is using Ghost behind Traefik in Docker, the workaround is to create an external link that maps your domain name to the traefik server. For example:

services:
  ghost:
    external_links:
      - traefik:xobs.io

With the fix, I have no more errors in the log. However the issue remains that it’s telling me I need to upgrade.

4

You’re running a pretty non-standard setup - so it’'s not easy to guess why the notifications aren’t clearing for you.

Ghost needs to contact a central server in order to get these notifications. Is it possible that this was allowed, the notification was picked up, and then your setup changed so that Ghost is no longer able to reach the update service?

Can you inspect the DB and see what the result is for

select * from settings where `key` = 'notifications';

Can you also share your config.*.json and confirm whether you’re running in dev or prod mode?

5

There is one entry in the notifications database:

{
  "dismissible": true,
  "location": "bottom",
  "status": "alert",
  "id": "f6eb6536-a655-44ac-a6a4-0f7574c7308b",
  "custom": true,
  "createdAt": "2020-03-13T11:26:05.000Z",
  "type": "info",
  "top": true,
  "message": "<strong>Ghost 3.0 is now available</strong> - You are currently using an old version of Ghost which means you don't have access to the latest features. <a href=\"https://ghost.org/3/\" target=\"_blank\" rel=\"noopener\">Read more!</a>",
  "seen": false,
  "addedAt": "2020-03-15T06:57:17.552Z"
}

There is no config.*.json – I’m using the official Docker images from Docker and configuring via environment variables.

This is a bit of a silly question – but is it the case that the notification must be dismissed? Should there be something that checks at startup to see if there are any old upgrade notifications and clears them if necessary?

6

Err, I assumed you’d done that and it wasn’t going away…

Standard upgrade notifications do go away when you upgrade, but this is a custom notification that you’re running a major version behind. It’s not tied to the version in any way, it’s just a thing that you need to see and acknowledge.

If you mark it as seen, it’ll should go away.

7

I thought it might have been a bug that it wasn’t going away, despite upgrading. I thought it had gotten into an invalid state, which is why it was recommending that I upgrade even though it had already done so.

That’s why I filed the issue. I didn’t want to touch the system, because I know how difficult it can be to replicate a system that’s in a failed state. I also know that systems in failed states can do unusual things, and I didn’t want to touch it if it was in an inconsistent state, such as being partially upgraded.

If it’s expected that the upgrade notification will stay around even after an upgrade, then I will go ahead and clear it.

8

At any rate, thank you for the help! Now I know a little bit more about how Ghost handles notifications, and that they’re just entries in the notifications table.

I’m sorry to have bothered you, and thank you for your support.

9

I didn’t want to touch the system, because I know how difficult it can be to replicate a system that’s in a failed state. I also know that systems in failed states can do unusual things, and I didn’t want to touch it if it was in an inconsistent state, such as being partially upgraded.

I appreciate that :slight_smile:

Despite appearances this is not a real upgrade notification :grimacing: - proper upgrade notifications are tied to versions and definitely go away when you upgrade. This is just a custom piece of text. |t’ll only go away when dismissed e.g. marked as read/seen.