PDA

View Full Version : SLES 12 SP4 SMT server mysql errors



imoore
12-Jun-2019, 03:59
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:

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


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

Jasan
12-Jun-2019, 06:27
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.

imoore
12-Jun-2019, 06:33
Glad it's not just me :-)
So maybe it's something SUSE have done in the update repos?

ataschner
13-Jun-2019, 07:10
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

Jasan
14-Jun-2019, 07:18
Yes, can confirm. I got the PTF 17766 yesterday. The sync is working now. Just ask the SUSE support.

ataschner
25-Jun-2019, 07:39
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

bsccns
27-Jun-2019, 15:38
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