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