RT upgrades causing segmentation faults under Debian Buster

Hey,

I’m working since the past year on a Request-Tracker 4.0.7 upgrade to 4.4.3 on a huge RT instance with several customizations. Meanwhile, Debian Buster was released and I tried to adapt the migration process to that. Unfortunately, I figured out, the rt-database-upgrade script does not work properly on Debian Buster.

To demonstrate that I screencasted a Debian Buster VM RT 4.0.7 installation and an upgrade attempt to RT 4.4.3. But even an upgrade from 4.4.3 to 4.4.4 will be stopped by the same errors: segmentation faults.

Screencast Debian Buster
Screencast Debian Stretch

You can reproduce this process by the following bash commands.

Maybe you have some ideas, meanwhile I’m will stick to Stretch and have to test if RT 4.4.3 will run smoothly after an update on Buster.

Cheers

Roman

The missing bash commands are linked here.

This issue was already described but never solved. I guess that’s related to that too.

Some of the “segmentation fault” upgrades do not perform database changes at all and are reproducible. That’s an indication that something in the Perl script is broken or a package/dependency corrupted.
Solving the dependencies completely by CPAN (make fixdeps) will cause the same issue, by the way.

Just a shot in the dark but I see you are manually setting the file permissions for the RT directory, the file rights should be handled when you run make install, there is also the make fixperms command that will fix file permissions.

Can you try running make fixperms and then the upgrade step or make fixdeps and see if its the same issue?

Hey, thank you for your suggestion.
I will try that but in that case Debian Stretch should behave the same way like Buster (file permissions are not fundamentally changed).

chmod -R 777 /opt/rt4/
does not have any effect

I set the permissions according make installs suggestions; its just copy-&-pasted.

As it seems to be having trouble with file permissions, I’d still be looking at making sure things like AppArmor and SELinux are (at least whilst debugging) disabled, as they can make traditional Unix style file permissions look fine but still cause failures. Also check for ACLs that have been applied. I’ve seen this so many times over the years - when we now hit an oddity at work one of the first suggestions is “have you disabled SELinux”?

Hey,

thank you for your post.

I checked SELinux, its by default disabled like AppArmor. AppArmor is even not installed in the minimal network Debian installation. During the screencast, I tried to stop AppArmor, but it is not present on the system.

make fixperms
does not change anything.

So it neither SELinux nor AppArmor nor file permissions (chmod -R 777) are solving the problem. And it’s not only applied during database upgrades.

As you can see, I used the pure vanilla Debian Buster Image. So nothing is “different” than the default settings.

The answers to linked posts are as well referred to file permissions and AppArmor/SELinux und the problem could not be solved.

I guess that’s something more complicated. I would like to encourage some developer just to install plain Debian Buster and to reproduce my procedure, or the basic installation and upgrade routine.

Is there a possibility to open an issue for the developer directly (like GitHub/GitLab issues)?

Honestly, it took a long time to break the issue down to Debian Buster, since everything works great on Debian Stretch with the identical steps.

That’s why I screencast the whole Debian setup, RT installation and upgrade. I could guess that’s something related to Perl or especially some functions or dependencies which are only used during the upgrades?

Next step I will perform tests on a Debian Stretch upgraded RT and subsequently upgrade Debian to Buster to see if RT behaves like expected. If yes, that could explain why there are not so many reports on that, since there are not a lot of RT upgrades after Debian Buster release. I’ll report the outcome.

Just to be able to reproduce, are you using system Perl or a standalone Perl for RT?

System perl:
$ apt install perl
as written in the second line.

Meanwhile I throw away the chown/chmods commands, since they are redundant. segfaults still appear

Ok, apply Debian Buster distribution upgrade after a successful RT 4.4.3 upgrade on Debian Stretch seems to work.
RT looks fine and works with my ~90 GB RT-MySQL-DB. Indicates, that something is wrong in the upgrade script.