Zammad crashed after 3.6 update? #2

Continuing the discussion from Zammad crashed after 3.6 update?:

Hi, during the migration from 3.4.0 to 5.3.0 I ran into the same issue but I was not able to fix it with your modified 20200121000001_smime_support.rb.

Any idea how to solve this?

Hello mssm,
I use zammad for a couple of years now (still mysql) and I had actually just very few minor upgrade issues like this one. I’m pretty sure this still works but I personally figured out that using docker is not always the best way, especially if you run in issues like this.
Because it has already been mentioned - I also recommend using the old SLES to upgrade to the current version and then switch to docker or whatever.

I’m absolutely not a ruby/rake expert but it seems the error is somewhere related with the following logline

ArgumentError: Trying to register Bundler::GemfileError for status code 4 but Bundler::GemfileError is already registered

which is not the error we experienced in the beforementioned thread. Here it is again obvious that changing the code is needed to cancel out that “already registered” part. It needs debugging and digging into code, but

grep -ir GemfileError

is your friend :wink:

Can you please stop open more and more threads around the same topic?
Do you really think that this raises your chance of getting any or better answers?

For me I’m out, sorry, I’m refusing to help you with that kind of attitude.

No idea how to solve that.
I found https://github.com/rubygems/rubygems/issues/3284 and tried
gem update --system 3.2.3 && gem update --system
but still running into the same error.

Interesting that you are using Zammad for years, we are trying this migration now since weeks. The only working step was 3.4->3.5 right at 3.6 was starting to fail. And up to current 5.* there are a lot steps left. I start to wonder if Zammad is ready for future use here. Sure we could start with an empty Zammad installation, but with the experience that future Zammad upgrades could potentially loose all data is far from optimal.

Sure I can. I’m just trying to split the many different issues into separate dedicated threads, especially because the 3.6 update issue was already being discussed in this thread. Beside that it’s kind of unusual to close threads automatically which was the reason to open another clone like this one.

The only duplication is having my main thread regarding the whole migration from 3.4 to 5.3: Migrating 3.4.0 to 5.3.0 - #9 by mssm where I’m referencing the single issue threads like this one.

Discourse does this automatically when the thread “dies”. One can’t configure that to off.

It is a setting on a category level.

There are also global settings on how to handle with “solved” topics.

Cheers,
Gijs

2 Likes

Oooooh thanks for the hint, I hadn’t this on my radar.

I tweaked the auto closes for non solved threads like so:

  • 12 month no thread update (new posts, was 4)
    • technical assistance
    • lobby
    • development
  • 4 years (was ~1month)
    • feature requests

Topics marked as “solved” will now close (initially wasn’t the case) within 7 days.

That should do.

2 Likes

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