Sync Gateway upgrade from 2.8 to 3.1 fails to start

I have a working Sync Gateway 2.8 install that I’m trying to upgrade to 3.1. It runs on Ubuntu 20.04 with a Couchbase 7.1.1 server on the same VM.

There is 1 database defined in sync_gateway.json, most everything is default.

I installed SG 3.1 using the sandard install command-line:
dpkg -i couchbase-sync-gateway-community_3.1.0_x86_64.deb

After it completed, sync_gateway wouldn’t start. Using journalctl -xe I noticed the following error in the logs:

Aug 28 16:50:29 sdpm-dev-vm bash[113824]: 2023-08-28T16:50:29.905-06:00 [ERR] Couldn't start Sync Gateway: Couldn't open config file: 1 errors:
Aug 28 16:50:29 sdpm-dev-vm bash[113824]: undefined environment variable '${t}' is specified in the config without default value -- rest.ServerMain() at main.go:33

I check the permissions on the configuration file and it should be accessible, especially as it worked before the upgrade.

$ systemctl show sync_gateway
...
Environment=RUNBASE=/home/sync_gateway GATEWAY=/opt/couchbase-sync-gateway/bin/sync_gateway CONFIG=/home/sync_gateway/sync_gateway.json [...]

dev@sdpm-dev-vm:~$ ll /home/sync_gateway/
total 40
drwxr-xr-x 4 root         root         4096 Aug 28 16:50 ./
drwxr-xr-x 5 root         root         4096 Dec 23  2021 ../
-rw-r--r-- 1 sync_gateway sync_gateway 1541 Apr  2 00:45 cert.pem
drwxr-xr-x 2 sync_gateway sync_gateway 4096 Dec 23  2021 data/
-rw------- 1 sync_gateway sync_gateway 1708 Apr  2 00:46 key.pem
drwxr-xr-x 2 sync_gateway sync_gateway 4096 Feb 16  2023 logs/
-rw-r--r-- 1 sync_gateway sync_gateway 1656 Aug 28 16:50 sync_gateway.json
-rw-r--r-- 1 root         root         1606 Aug 28 16:48 sync_gateway.json.b4_sg31
-rw-r--r-- 1 sync_gateway sync_gateway 5368 Jul 12  2022 sync_gateway-with_login_dbs.json

This is my sync_gateway.json:

dev@sdpm-dev-vm:~$ cat /home/sync_gateway/sync_gateway.json
{
  "adminInterface": "0.0.0.0:4985",
  "interface": "0.0.0.0:4984",
  "logging": {
    "console": {
      "log_level": "debug",
      "log_keys": ["*"]
    }
  },
  "CORS": {
          "origin":["http://localhost:8000"],
          "loginOrigin":["http://localhost:8000"],
          "headers":["Content-Type"],
          "maxAge": 1728000
  },
  "SSLKey": "/home/sync_gateway/key.pem",
  "SSLCert": "/home/sync_gateway/cert.pem",
  "bootstrap": {
    "use_tls_server": false
  },
  "databases": {
    "licensees": {
      "server": "couchbase://127.0.0.1",
      "username": "sg_app",
      "password": "[...]",
      "bucket": "bucket-licensees",
      "enable_shared_bucket_access": true,
      "import_docs": true,
      "users": {
        "GUEST": { "disabled":true, "admin_channels":["*"] },
        "admin": { "password":"[...]", "admin_channels":["*"], "disabled":false },
        "mike.totman@safedoorpm.com": { "password":"[...]", "admin_channels":["just-docks-dev-local","just-doors-dev-local"], "disabled":false }
      },
      "sync": `function(doc, oldDoc) {
                if (doc.doc_type) {
                    if (doc.licensee_id === undefined ) {
                        channel("!");
                    } else if (doc.doc_type === "Licensee") {
                        channel(doc._id)
                        requireAccess(doc._id)
                    } else {
                        channel(doc.licensee_id);
                        requireAccess(doc.licensee_id);
                    }
                }
        }`,

      "allow_conflicts": false,
      "revs_limit": 20,
      "num_index_replicas": 0
    }
  }
}

Any idea why it would be unable to read the config file and why it’s complaining about this ${t} variable?

Do I need to clear out my configuration file and replace it with a bootstrap version? The SG 3.1 Upgrade page made it sound like it would be automatically upgraded by the installation.
"

Upgrade to 3.1

Use Persistent Configuration

The use of 3.x’s Persistent Configuration feature is strongly recommended. It is the default operational mode when starting sync gateway.

The feature provides a smooth upgrade path for existing users by automatically converting their existing configuration files to the new persistent configuration format.
"

Aha, I figured it out. I was still on the Install step and if I proceeded to the Verify step and replaced the sync_gateway.json configuration file with the bootstrap version included in that page, then it started up. Of course, it doesn’t have any of my existing configuration, like the database, which is annoying, but I can manage that, I suppose.

The docs sure made it sound like it would migrate that configuration for me:

The feature provides a smooth upgrade path for existing users by automatically converting their existing configuration files to the new persistent configuration format.

Did I do it wrong?

After struggling with it further, trying to .../_resync the _default._default scope and failing, and seeing that SG 3.1 appears to finally remove support for old style CouchDB views, which our app still uses, I don’t think we’re ready for Sync Gateway 3.1.

Also, I’m not sure this upgrade process and documentation is very clear, based on my problems here

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.