Forum Home
Press F1
Thread ID: 86602	2008-01-22 03:31:00	MySQL & nscd	Erayd (23)	Press F1

Post ID	Timestamp	Content	User
632756	2008-01-22 03:31:00	I am having a not-so-small problem with MySQL on Linux. It refuses to start, and spits out a stack trace, unless nscd is installed, running, and has caching enabled. I'm using libnss-mysql (libnss-mysql.sourceforge.net/) for account management etc, but even if I declare the MySQL account / group locally in passwd it still has the same problem whenever any 'weird' account service is used. Google hasn't been much help; it's turned up a few related bugs, but nothing solid. I can live with the nscd requirement, but not the requirement that caching be enabled. OS: Debian Lenny x86 Any help will be much appreciated. Thanks, Bletch	Erayd (23)
632757	2008-03-05 09:55:00	Bump ^. :crying	Erayd (23)
632758	2008-03-05 19:35:00	I think what you're doing is well outside the scope of people's knowledge here...	somebody (208)
632759	2008-03-05 19:43:00	Yeah... I came to a similar conclusion a long time ago, but I bumped it anyway in the forlorn hope that someone who actually knows the answer may notice it - I'm still having this problem, and both google and #mysql have proved fruitless.	Erayd (23)
632760	2008-03-06 05:14:00	I assume you are storing your user accounts in the MySQL DB? If so then the caching is certainly a must as do not forget that every single file access / operation requires that the UID and GID be verified and there can be a problem when it takes time to fetch the data from the DB. The caching bypasses the need for the delay / wait for the backend and also helps with the "chicken & egg" syndrome. Have a look at some of the information for doing the same thing with LDAP as it explains very well the issues.	ughnz (8297)
632761	2008-03-06 06:47:00	I assume you are storing your user accounts in the MySQL DB?No. The user accounts & groups are stored in MySQL, but on a different machine, not the affected one. If so then the caching is certainly a must as do not forget that every single file access / operation requires that the UID and GID be verified and there can be a problem when it takes time to fetch the data from the DB.This is a home network with a lightly loaded server. The response is returned to the machine making the query in ~2ms, and the query time shouldn't make a difference anyway unless there are race conditions in the library - which as far as I'm aware there aren't, otherwise it'd also be having issues with slow disk access. The caching bypasses the need for the delay / wait for the backend and also helps with the "chicken & egg" syndrome.The cache retrieval shaves almost nothing off the time taken, so I'm pretty certain this isn't the cause of the problem. There is also no chicken & egg issue, as the accounts are not stored on the local machine. Have a look at some of the information for doing the same thing with LDAP as it explains very well the issues.I did. Sadly, it got me nowhere :crying. Any other ideas?	Erayd (23)
632762	2008-03-06 08:02:00	Have you tried starting the server with no work stations active and seeing if MySQL will load OK?	ughnz (8297)
632763	2008-03-06 08:58:00	Have you tried starting the server with no work stations active and seeing if MySQL will load OK?Yes - as I said earlier, the account server has no problems whatsoever. My issue is with running MySQL on other machines when libnss-mysql is used as the account & group source. The server (obviously) is not trying to authenticate to its own database during init, that would be stupid - the server uses bog standard normal files (passwd & group) as the default option.	Erayd (23)
632764	2008-03-07 21:46:00	Umm.. I wonder if at some stage in the boot process you are temporally loosing network connectivity before MySQL is launched, hence the reason why the caching will allow MySQL to load. I also assume you have checked the UID & GID for MySQL account is correct in the DB for the workstation? and that the group memberships are correct? I assume that once libnss-mysql is enabled then local passwd / group is ignored so why not try only enabling libnss-mysql at the end of the boot process? I do not think anyone could be of any more help with out being in front of the workstation with the problem to see what is going on.	ughnz (8297)
632765	2008-03-07 22:27:00	Umm.. I wonder if at some stage in the boot process you are temporally loosing network connectivity before MySQL is launched, hence the reason why the caching will allow MySQL to load.This is possible - I'm not sure why it would be the case (because it should fall back to passwd/group), but maybe sleeping init to give the network some time to come back up would help.... I'll try it. Good idea, thanks :D. I also assume you have checked the UID & GID for MySQL account is correct in the DB for the workstation? and that the group memberships are correct?Yes, these are correct. I assume that once libnss-mysql is enabled then local passwd / group is ignored so why not try only enabling libnss-mysql at the end of the boot process?Nope - I have it as a priority set. It will try MySQL first, but if it can't get a valid response from MySQL it will fall back on the standard passwd/group files. These files contain enough information to boot the machine completely. I do not think anyone could be of any more help with out being in front of the workstation with the problem to see what is going on.Would boot logs help? Edit: Note that this isn't just a boot problem. If I boot the machine, then disable caching and/or remove nscd, then restart MySQL, it will fail. However the account info is still available, and every other program on the machine that requires this information still works just fine.	Erayd (23)
1 2