SMT server mysql errors

SUSE Product Topics SLES Updates
1

I have an SMT server running on SLES12SP4.
Suddenly on 5th June it started throwing an error when doing an smt-scc-sync. Here’s the outup of the scc sync:

[COLOR="#008000"]Downloading Product and Repository information
Downloading Subscription information
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.
DBD::mysql::db do failed: Data too long for column ‘SUBNAME’ at row 1 at /usr/lib/perl5/vendor_perl/5.18.2/SMT/SCCSync.pm line 1556.

Error while fetching Subscriptions data.
Downloading Order information
Downloading Orders skipped
Flagging repositories which can be mirrored
[/COLOR]

Any idea what would cause that? I had patched the server a couple of days earlier, but the sync worked correctly that evening and the following, so presumably that wasn’t the cause of the errors.
The rest of the sync and the SMT Mirror don’t report any errors, so I don’t believe it’s something like a proxy/firewall error.

Cheers, Ian

2

Same on my SMT installation on SLES 12 SP3 (smt-3.0.41-52.35.1.x86_64).
Last system update was on 31/05/2019.
I opened a support ticket on SCC.

3

Glad it’s not just me :slight_smile:
So maybe it’s something SUSE have done in the update repos?

4

Hi

These are harmless yet annoying messages caused by newer subscriptions with longer information than what the SMT database is currently set up for.

SUSE has developed a fix that will be submitted for a maintenance update for the SMT package.

If this is a great concern for your organization, please reach out to SUSE support, who may be able to provide you a hot-fix for the interim.

//Andreas

5

Yes, can confirm. I got the PTF 17766 yesterday. The sync is working now. Just ask the SUSE support.

6

For the records, the SMT maintenance update addressing this has been released.
So no need to contact SUSE support about this - just fetch it for your SLES version at https://scc.suse.com/patches or https://download.suse.com/patch/finder/
//Andreas

7

We had the same issue with SMT and SLES 12 SP4.

Upgrading to the latest smt version it worked now.

Repository : SLES12-SP4-Updates Name : smt Version : 3.0.42-52.38.1 Arch : x86_64

After upgrading the package a notification was shown telling that the database schema have changed and should be upgraded using the following command or in the next smt.target restart.

/usr/bin/smt-schema-upgrade