Sorry if this is not the correct category for this. I’m evaluating discourse and the VersionCheck Job is failling in my environment. I’ve noticed that failed jobs are piling up inside sidekiq and probably will get moved to the “dead” section after the default 25 retries (as per RubyDoc.info: Class: Sidekiq::JobRetry – Documentation for sidekiq (8.1.6) – RubyDoc.info). I know that I need to investigate what is causing it to fail, but the point here is: Does it make sense to maintain these jobs there? Isn’t best to simply discard failed version checks and wait the next job execution? At this moment I have more than 80 VersionCheck jobs waiting for retry and to me it looks like a waste of resources (probably little, but still a waste)… From what I’ve checked, adding sidekiq_options retry: false to app/jobs/scheduled/version_check.rb would solve this. Am I missing something?

[תמונה] Bruno_Salazar: I know that I need to investigate what is causing it to fail How did you install? Is there reason to believe you have network issues? Ram? [תמונה] Bruno_Salazar: it looks like a waste of resources (probably little, but still a waste)… You may be right, but since you’re the only person to report this (at least so far) it’s not made it on the list of optimizations. It does make sense to just let it fail after one try,I’d think.

[תמונה] pfaffman: How did you install? I’m using the standard docker install inside an ec2 instance. [תמונה] pfaffman: Is there reason to believe you have network issues? Ram? I’m in a corporate environment, so there are lots of firewall, proxies and security scanners between the instance and the internet. In the logs I see a “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)” error, so probably some firewall is denying the request at some point… I’m still understandig how discourse does this version checks so I can reproduce them by hand and get more details. [תמונה] pfaffman: You may be right, but since you’re the only person to report this (at least so far) it’s not made it on the list of optimizations. It does make sense to just let it fail after one try,I’d think. Totally understand this. In the past I’ve worked with gitlab and seen lots of issues where full sidekiq queues caused performance degradation and other weird behaviours so everytime I see something like this my alarms ring. :smile:

[תמונה] Steven: When was the last time you upgraded? I’m on 2.8.0.beta9 (959923d3cf) [תמונה] Steven: If you upgrade in the terminal (./launcher rebuild app), it should be ok. Yeah… The upgrade in the terminal or via GUI is working OK (runing it on a weekly basis). The only issue in this case is that the main administrator screen doesn’t show the latest version and always says that i’m running an outdated version.

[תמונה] Bruno_Salazar: the main administrator screen doesn’t show the latest version and always says that i’m running an outdated version. Then you should definitely run a command line upgrade

[תמונה] Bruno_Salazar: I’m in a corporate environment, so there are lots of firewall, proxies and security scanners between the instance and the internet. Discourse will reach out to the internet for tasks like checking version upgrades, fetching user avatars, downloading remote images to local storage, and general oneboxing. If the instance is severed from the internet, there will be some breakage indeed.

[תמונה] pfaffman: Then you should definitely run a command line upgrade Yes! I’m doing it every week until I find a solution. [תמונה] Falco: If the instance is severed from the internet, there will be some breakage indeed. I had to give up on oneboxing exactly for this reason. For now I can’t allow full internet access for this server. github.com/* is already allowed, but probably this versioncheck job uses another URL to do this.

[תמונה] Bruno_Salazar: Yes! I’m doing it every week until I find a solution. What I’d do is just turn off SiteSetting.version_checks, remove the discourse_docker plugin and do command line upgrades. But, here, if you can open up https://api.discourse.org/api, then you’re probably good. lib/discourse_hub.rb main if raise_on_error && response.status != 200 raise Error.new(rel_url, response.status, parse_body(response.body)) end JSON.parse(response.body) end def self.collection_action(action, rel_url, params = {}, raise_on_error: false) connect_opts = connect_opts(params) response = Excon.public_send( action, "#{hub_base_url}#{rel_url}", { body: JSON[params], headers: { "Referer" => referer, "Accept" => accepts.join(", "), "Content-Type" => "application/json", },

[תמונה] pfaffman: But, here, if you can open up https://api.discourse.org/api , then you’re probably good. Thank you for the info! It worked when I allowed access to https://api.discourse.org/api/version_check

התנהגות משימות VersionCheck שנכשלו

מפתח

Steven 5 בדצמבר,‏ 2021,‏ 1:14pm 3

When was the last time you upgraded?

There was an issue with the version check job a few weeks ago (around end of october), it is fixed now. If you upgrade in the terminal (./launcher rebuild app), it should be ok.

נושא		תגובות	צפיות
Botched restore led to Sidekiq job failures Product Support	6	714	18 בינואר,‏ 2022
Auto-update issue - "Ensure sidekiq is running." Product Support	2	1744	3 בדצמבר,‏ 2015
Sidekiq not running Self-hosting	21	5693	19 ביוני,‏ 2017
"Ensure sidekiq is running." when it is definitely running Self-hosting	18	8274	2 באוקטובר,‏ 2015
Sidekiq error message Product Support	3	571	2 בנובמבר,‏ 2021

התנהגות משימות VersionCheck שנכשלו

נושאים קשורים