[Bug 539148] New: mysql fails to start after update
http://bugzilla.novell.com/show_bug.cgi?id=539148 Summary: mysql fails to start after update Classification: openSUSE Product: openSUSE 11.2 Version: Milestone 7 Platform: Other OS/Version: All Status: NEW Severity: Major Priority: P5 - None Component: Update Problems AssignedTo: mhrusecky@novell.com ReportedBy: suse-beta@cboltz.de QAContact: jsrain@novell.com Found By: Beta-Customer I updated from 11.1 to 11.2 M7 with zypper dup. Now MySQL fails to start. mysqld.log contains: 090914 17:57:02 InnoDB: Started; log sequence number 0 2558255979 090914 17:57:02 [ERROR] /usr/sbin/mysqld: unknown option '--skip-federated' 090914 17:57:02 [ERROR] Aborting (At least the error message is helpful - commenting out skip-federated in my.cnf solves the issue.) The reason why I report this as bug: skip-federated was a default config option in 11.1, which makes this a serious update problem for many installations. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=539148
User mhrusecky@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c1
Michal Hrusecky
http://bugzilla.novell.com/show_bug.cgi?id=539148
User binner@kde.org added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c2
--- Comment #2 from Stephan Binner
http://bugzilla.novell.com/show_bug.cgi?id=539148
User suse-beta@cboltz.de added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c3
Christian Boltz
Is this mentioned in the 11.2 release notes?
No, it is not. (In reply to comment #1)
See /usr/share/doc/packages/mysql/README.SuSE (as mentioned by rc script during upgrade of mysql storage):
"during upgrade of mysql storage" is too late because this upgrade can only happen after fixing the configfile. In other words: _after_ fixing the configfile. (Chicken and egg anyone? ;-) Before fixing the configfile, MySQL just fails to start without any visible error message. Basically, the whole /usr/share/doc/packages/mysql/README.SuSE should be copied to the release notes. I just opened bug 539243 for that. Regarding the configuration change: I strongly recommend to comment out the skip-federated config option with a rpm %post script. (BTW: I would prefer this over a non-starting MySQL ;-) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=539148
User mhrusecky@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c4
Michal Hrusecky
http://bugzilla.novell.com/show_bug.cgi?id=539148
User suse-beta@cboltz.de added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c5
--- Comment #5 from Christian Boltz
I still can imagine cases when I would hate even such a minor automatic change in my configuration file...
You prefer to have a broken config? ;-) Seriously: I can't imagine such a case, so please tell me which cases you see.
And I guess there wouldn't be much openSUSE users touching configuration file and not reading rc script output...
Often there are some months between editing my.cnf and upgrading to a new openSUSE version. Let me say it this way: I'll check the rc script output if something doesn't work...
I'll try to think about some safe way how to accomplish this.
The following sed call should work: sed -i '/^skip-federated$/d' /etc/my.cnf This will delete the ^skip-federated$ line, and the regex makes sure that modified lines are not deleted. (I'm not a packaging expert, but I think you'll need to PreReq: sed for this.) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=539148
User suse-beta@cboltz.de added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c6
--- Comment #6 from Christian Boltz
sed -i '/^skip-federated$/d' /etc/my.cnf
or, if you prefer to comment out the line: sed -i 's/^skip-federated$/# skip-federated # obsolete/' /etc/my.cnf -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=539148
User mhrusecky@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=539148#c7
Michal Hrusecky
(In reply to comment #4)
I still can imagine cases when I would hate even such a minor automatic change in my configuration file...
You prefer to have a broken config? ;-) Seriously: I can't imagine such a case, so please tell me which cases you see.
Ok, some hypothetical cases are that somebody might want to run two different versions of MySQL on the same machine or using same configuration file for different machines. But there can be even more probable example. Let's say that I don't have free space in etc. Well, then installation will probably fail, but with automatic editing of configuration file, it can be deleted during editing. Well main problem is that when I start changing configuration file, where should I stop? And once I'll touch configuration file, people will expect that everything will be fixed. But there are clearly some cases when I can't fix everything. And I prefer either completely working configuration file or my own configuration file. And not something in the middle. Other change I decided to introduces is the default location of the pid file and the socket file. People will expect that their applications will be running. Hopefully in 11.2 all applications will expect socket file in new location. But what about their own applications? So I'm not going to update socket location (but I'm thinking about adding workaround for users). And now let's speak hypothetically about possible outcome. Let's say that I'll automatically fix skip-federated thing. Then people will be at first sight happier that their MySQL is running. After while, they'll realize that their PHP applications can't connect to MySQL and that phpMySQLAdmin can't connect to MySQL either. Then they will start looking around what's wrong. As MySQL is running it will probably take them quite some time to realize that mysql.sock should be elsewhere. I personally would prefer the case when MySQL wouldn't start telling me that I should check my configuration file. In this way, I'll be forced to read the README.
And I guess there wouldn't be much openSUSE users touching configuration file and not reading rc script output...
Often there are some months between editing my.cnf and upgrading to a new openSUSE version. Let me say it this way: I'll check the rc script output if something doesn't work...
And it will tell you what's wrong... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com