When using named with a mysql DLZ, you have to make sure mysql starts before named, so that it can connect to the database. This is done by setting rc_named_use="mysql" rc_named_after="mysql" in /etc/conf.d/named Doing so, though, creates a deadlock because mysql in turn, expects named to be running already. So, at boot time, this is what happens when mysql should be running: * named: waiting for mysql (50 seconds) * named: waiting for mysql (41 seconds) ............ and then, when named should be running: * mysql: waiting for named (50 seconds) * mysql: waiting for named (41 seconds) .......... The only workaround for this is to remove all but "localmount" and "net" parameters from the depend() function in the /etc/init.d/mysql script. Reproducible: Always Steps to Reproduce: 1. Uncomment the following lines in /etc/conf.d/named rc_named_use="mysql" rc_named_after="mysql" 2. Reboot or restart the mysql and named services Actual Results: MySQL and BIND don't start as they depend on eachother. Expected Results: MySQL should start and then BIND should start This could also happen with PgSQL, although I have not tried it.
> When using named with a mysql DLZ, you have to make sure mysql starts before > named, so that it can connect to the database. According to the recent trend started by Lennart Poettering, this is false. Services should be able to start in any order, and dependencies ideally should not exist at all. What happens if you don't specify this dependency? I.e. does bind eventually reconnect to mysql if it is started before mysql? If this is true (and it should be true, but please verify), NOTABUG. Does bind support reconnecting to mysql at all (i.e., can I restart mysql while bind is running)?
(In reply to comment #1) > > When using named with a mysql DLZ, you have to make sure mysql starts before > > named, so that it can connect to the database. > > According to the recent trend started by Lennart Poettering, this is false. > Services should be able to start in any order, and dependencies ideally should > not exist at all. > I understand this and it seems natural, I agree. > What happens if you don't specify this dependency? I.e. does bind eventually > reconnect to mysql if it is started before mysql? If this is true (and it > should be true, but please verify), NOTABUG. No, BIND does *not* start at all if it cannot load the DLZs (aka connect to the database). > > Does bind support reconnecting to mysql at all (i.e., can I restart mysql while bind is running)? No, restarting mysql (and thus, severing the existing connection) causes the DLZs to become unavailable (although BIND will continue to act as a caching/forwarding server).
OK, the bug is valid then.
What version of mysql-init-scripts are you using? Check /etc/conf.d/mysql and make sure it does not depend on DNS. Be warned that means you won't be able to use hostnames in your ACLs not present in /etc/hosts.
I'm using dev-db/mysql-init-scripts v1.2, the latest in amd64 stable. [IP-] [ ] dev-db/mysql-init-scripts-1.2:0 In the /etc/conf.d/mysql file there is nothing (basically all the lines are commented out) and there's no mention of DNS setup whatsoever in there. However, my /etc/init.d/mysql file has the following depend() function body: depend() { use dns net localmount netmount nfsmount } Disabling the dependency "dns" in the init script is not really enough, because it also depends on "netmount" and "nfsmount", both of which indirectly depend on "dns". Thus, in order to get mysql up and running before BIND, all 3 (dns, netmount, nfsmount) need to be eliminated from the dependency list in the init script, basically only leaving "net" and "localmount" in there.
Please test with the mysql-init-scripts-2.0_pre1-r2 ebuild. @Robin: time to get the newer version marked stable?
(In reply to comment #6) > Please test with the mysql-init-scripts-2.0_pre1-r2 ebuild. > I can confirm that upgrading mysql-init-scripts to 2.0_pre1-r2 solves the circular dependency problem. MySQL starts now with no problem if BIND isn't started. However, if I enable the rc_named_use="mysql" rc_named_after="mysql" options in /etc/conf.d/named and then do # /etc/init.d/named start *before* I start mysql, I get the following thing: Ares-VM-Coderollers init.d # /etc/init.d/named start * mysql: waiting for named (50 seconds) * mysql: waiting for named (41 seconds) Doing a rc-update -u has no effect and BIND fails to start mysql automatically. However, starting MySQL prior to this and then starting BIND works like a charm. I just wish I knew that happens all the time during boot time as well :-)
(In reply to comment #7) > (In reply to comment #6) > > Please test with the mysql-init-scripts-2.0_pre1-r2 ebuild. > > > I can confirm that upgrading mysql-init-scripts to 2.0_pre1-r2 solves the > circular dependency problem. MySQL starts now with no problem if BIND isn't > started. Ok, let's stabilize it. > However, starting MySQL prior to this and then starting BIND works like a > charm. I just wish I knew that happens all the time during boot time as well > :-) MySQL _should_ have been started first here. I'm wondering if there is something cached badly in your system.
(In reply to comment #8) > MySQL _should_ have been started first here. I'm wondering if there is > something cached badly in your system. I will try it on a "clean" setup and come back with a conclusion.
(In reply to comment #9) > (In reply to comment #8) > > MySQL _should_ have been started first here. I'm wondering if there is > > something cached badly in your system. > > I will try it on a "clean" setup and come back with a conclusion. Indeed, something is bogus on that particular system. On a clean install, it behaves as intended.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > MySQL _should_ have been started first here. I'm wondering if there is > > > something cached badly in your system. > > > > I will try it on a "clean" setup and come back with a conclusion. > > Indeed, something is bogus on that particular system. On a clean install, it > behaves as intended. Closing as INVALID then. In any case, I've opened bug 397925 to get the new mysql-init-scripts version marked stable.
