Currently getting this bug Running the latest discourse [image] and here is the /sidekiq [image]

Yup the job only runs once a day so it might take awhile before it clears :wink:

Also encounted such problem. Tried rebuild and restart, both not working.

This problem is the result of a query not being sent properly from the VersionCheck job. It is failing because when it goes to check the version, the query isn’t included and thus a bad response comes back. There was also an issue with the port number, IIRC. There is a pull request pending on the fix. I did not make the fix, but I did manually apply the code changes to my install and it fixed the issue.

yes its the recommended docker based install

Yes let’s get this fixed asap @tgxworld

geez…I might just switch us to use Ruby’s built-in HTTP library. Just a simple get request and Excon gets in the way. Anyway, this has been fixed by @AlbertA in [image] JSON::ParserError on Jobs::VersionCheck Bug Hi! I just installed a forum on an ubuntu 16.04 linode instance using docker instructions. I also created an instance on a local VM so I could import my old smf2 based forum to it. Once imported I created a backup in the local VM through the discourse backup tab. I then applied this backup onto my linode instance following these instructions: Everything seems to work fine except the version check in the admin dashboard: “A check for updates has not been performed. Ensure sidekiq is running…

Why do we even need a third party library for this?

It has sort of been the convention in our repository to use either RestClient or Excon to make external requests. These third party clients provide a wrapper around the HTTP library which usually makes the code less verbose. While that is true for RestClient, I don’t think the same can be said for Excon. However, we don’t like RestClient because it depends on the mime-type gem that takes up quite a bit of memory. Once the latest mail gem is released, we’ll be able to drop the dependency on mime-type and switch to @sam’s mini-mime gem.

I am currently getting the same issue, even after rebuilding the container from SSH to latest.

i am getting this when running ./launcher logs app ok: run: postgres: (pid 214) 1s supervisor pid: 208 unicorn pid: 233 2017-06-19 08:17:50.172 UTC [375] discourse@discourse LOG: duration: 105.753 ms execute : SELECT "posts".* FROM "posts" WHERE ("posts"."deleted_at" IS NULL) AND "posts"."user_deleted" = 't' AND "posts"."deleted_at" IS NULL AND (NOT EXISTS ( SELECT 1 FROM topics t WHERE t.deleted_at IS NOT NULL AND t.id = posts.topic_id )) AND (updated_at 1) AND (NOT EXISTS ( SELECT 1 FROM post_actions pa WHERE pa.post_id = posts.id AND pa.deleted_at IS NULL AND pa.post_action_type_id IN (3,4,7,8) )) ORDER BY "posts"."id" ASC LIMIT 1000 206:M 19 Jun 08:22:28.041 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:22:28.054 * Background saving started by pid 1394 1394:C 19 Jun 08:22:28.336 * DB saved on disk 1394:C 19 Jun 08:22:28.337 * RDB: 30 MB of memory used by copy-on-write 206:M 19 Jun 08:22:28.368 * Background saving terminated with success 206:M 19 Jun 08:27:29.005 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:27:29.010 * Background saving started by pid 1808 1808:C 19 Jun 08:27:29.248 * DB saved on disk 1808:C 19 Jun 08:27:29.249 * RDB: 30 MB of memory used by copy-on-write 206:M 19 Jun 08:27:29.321 * Background saving terminated with success 206:M 19 Jun 08:32:30.070 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:32:30.072 * Background saving started by pid 2167 2167:C 19 Jun 08:32:30.369 * DB saved on disk 2167:C 19 Jun 08:32:30.370 * RDB: 32 MB of memory used by copy-on-write 206:M 19 Jun 08:32:30.420 * Background saving terminated with success 206:M 19 Jun 08:37:31.100 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:37:31.104 * Background saving started by pid 2508 2508:C 19 Jun 08:37:31.458 * DB saved on disk 2508:C 19 Jun 08:37:31.461 * RDB: 36 MB of memory used by copy-on-write 206:M 19 Jun 08:37:31.511 * Background saving terminated with success 206:M 19 Jun 08:42:32.022 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:42:32.032 * Background saving started by pid 2859 2859:C 19 Jun 08:42:32.400 * DB saved on disk 2859:C 19 Jun 08:42:32.402 * RDB: 36 MB of memory used by copy-on-write 206:M 19 Jun 08:42:32.440 * Background saving terminated with success 206:M 19 Jun 08:47:33.096 * 10 changes in 300 seconds. Saving... 206:M 19 Jun 08:47:33.099 * Background saving started by pid 3339 3339:C 19 Jun 08:47:33.339 * DB saved on disk 3339:C 19 Jun 08:47:33.340 * RDB: 32 MB of memory used by copy-on-write 206:M 19 Jun 08:47:33.402 * Background saving terminated with success

Sidekiq not running

Product Support Self-hosting

fefrei (Felix Freiberger) June 19, 2017, 1:40pm 21

Remember that this message is only updated by an occasionally running Sidekiq job, so it may take some time to update even after Sidekiq is started

Topic		Replies	Views
"Ensure sidekiq is running." when it is definitely running Self-hosting	18	8267	October 2, 2015
After a clean install : Sidekiq error Bug	17	2743	December 7, 2015
Sidekiq is consuming too much memory, restarting Self-hosting	38	9552	October 13, 2020
Sidekiq stops after some time Self-hosting	7	1363	June 14, 2023
Sidekiq not running. Sidekiq heartbeat test failed, restarting Self-hosting unsupported-install	14	3272	May 11, 2020

Sidekiq not running

Related topics