Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 14, 2012, at 5:18 PM, Paul Beard wrote: Turns out some applications won't work if you move the socket if they are configured to access localhost. Seems like a misunderstanding of networking if you can specify a port number in a configuration file but the application looks to the filesystem for the socket. There is no way to specify a file location so it seems doomed to fail — as it did. Something looking for a network location specified as a host and port (ie, localhost:3306) is using a TCP socket. Something looking for /tmp/mysqld.sock is using a UNIX domain socket. Changing the path to the UNIX domain socket will have no effect upon the port used by the TCP socket, or vice versa. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 8:17 AM, Chuck Swiger wrote: Something looking for a network location specified as a host and port (ie, localhost:3306) is using a TCP socket. Something looking for /tmp/mysqld.sock is using a UNIX domain socket. Changing the path to the UNIX domain socket will have no effect upon the port used by the TCP socket, or vice versa. Useful clarification but a UNIX domain socket sounds less like networking and more like interprocess communication, i.e., something explicitly tied to a single host. There is a skip networking option for MySQL that references the domain socket for use by processes on the same host but doesn't accept connections on port 3306. There's no indication that using localhost will default to a domain socket which will explicitly be looked for in /tmp and if you put it anywhere else, you must specify a hostname to access the TCP socket. I'll quote your definition in the bug report as it seems crystal clear. -- Paul Beard Are you trying to win an argument or solve a problem?
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 8:43 AM, Paul Beard wrote: Useful clarification but a UNIX domain socket sounds less like networking and more like interprocess communication, i.e., something explicitly tied to a single host. Yes, that's right. There is a skip networking option for MySQL that references the domain socket for use by processes on the same host but doesn't accept connections on port 3306. That also sounds familiar. There's no indication that using localhost will default to a domain socket which will explicitly be looked for in /tmp and if you put it anywhere else, you must specify a hostname to access the TCP socket. You're confusing two things which are different. If you specify a path via --socket=/tmp/mysqld.sock, you are describing a UNIX domain socket. While you can also specify --host=localhost, that would be ignored because it it implicit. If you change where the socket lives in mysqld config or CLI options, you need to change where the clients look for the socket as well. If you specify a hostname and port via --host=localhost --port=3306, then you are describing a TCP socket. There is no pathname involved. You could connect regardless of where mysqld is putting the socket. I'll quote your definition in the bug report as it seems crystal clear. I would have said that the documentation seem clear as well: http://dev.mysql.com/doc/refman/5.5/en/multiple-server-clients.html http://dev.mysql.com/doc/refman/5.5/en/multiple-unix-servers.html ...but there's evidently some confusing aspect. Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 15, 2012, at 9:20 AM, Chuck Swiger wrote: You're confusing two things which are different. At the risk of boring everyone on this list, I think I understand it as far as I need to: I am not the developer of the app(s) that seem to generate this issue. If you specify a path via --socket=/tmp/mysqld.sock, you are describing a UNIX domain socket. While you can also specify --host=localhost, that would be ignored because it it implicit. If you change where the socket lives in mysqld config or CLI options, you need to change where the clients look for the socket as well. If you specify a hostname and port via --host=localhost --port=3306, then you are describing a TCP socket. There is no pathname involved. You could connect regardless of where mysqld is putting the socket. If I gave the impression I didn't understand this, my mistake. The app configurations are not this granular: hostname and port are configured but there is nothing that makes clear that IF you specify localhost, you WILL BE using a domain socket which MUST BE /tmp/mysql.sock and IF you move it or your distribution prefers some other location you MAY NOT use localhost as you are now using a TCP socket which shouldn't require a hostname but because of the way the app is written, it does. Put another way, if you specify localhost, the port is ignored: I just tested this by setting the port to with a symlink to the socket placed in /tmp. It worked fine. If you change the location of the socket, you MUST use a TCP socket which mean identifying the host by name, not as localhost, even if it is localhost. There is no way to specify the location of the domain socket. It must be in /tmp. Note I am not arguing that the use of localhost requires a named domain socket, in UNIX, just that it does in this app. I learned a couple of things here. I hope I can make them clear to the people who need 'em. -- Paul Beard Are you trying to win an argument or solve a problem?
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On 15/01/2012 17:20, Chuck Swiger wrote: If you specify a hostname and port via --host=localhost --port=3306, then you are describing a TCP socket. There is no pathname involved. You could connect regardless of where mysqld is putting the socket. Some MySQL clients will gratuitously change a connection attempt to localhost to use the /tmp/mysql.sock unix domain socket because it does perform a bit faster, and it seems they don't expect their users to just ask for a socket connection explicitly. You can test this fairly simply: set up your server with 'skip-networking' temporarily and try making client connections to it. Of course, for some language API's there's no option but to use a network socket -- Java being a case in point -- but that's the exception rather than the rule. To force the command line mysql(1) client to use a network connection to localhost you need to use the --protocol=TCP argument Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On 15/01/2012 17:50, Paul Beard wrote: The app configurations are not this granular: hostname and port are configured but there is nothing that makes clear that IF you specify localhost, you WILL BE using a domain socket which MUST BE /tmp/mysql.sock and IF you move it or your distribution prefers some other location you MAY NOT use localhost as you are now using a TCP socket which shouldn't require a hostname but because of the way the app is written, it does. You can specify an alternate socket location in your connection parameters. For the command line client, it is: mysql -S /var/run/mysql/sock This doesn't help if you say 'mysql -h localhost' and get diverted to use the default socket though -- in that case you can have a .my.cnf file containing (inter-alia) [client] socket = /var/run/mysql/sock For the various language APIs, you generally need to specify a DSN string -- usually this looks something like mysql:database=$database;host=$hostname;port=$port but for a socket connection you could say instead: mysql:database=$database;mysql_socket=/var/run/mysql/sock ... assuming that whoever wrote the application you're using made it sufficiently flexible as to be able to accept something like that. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Solution: mysqld fails to run, can't create/find mysql.sock
Woke up to a screenful of error messages about failed mysql backups and found that for some reason, mysql was refusing to run at all. The issue was not just a missing mysql.sock but an inability to create one. I could do it by hand or at least create a file with the same name and permissions but it would be removed on the next attempt and then not replaced. Turns out the permissions on /tmp were not right. I didn't note them beforehand but setting them 1777 solved it. I would be interested in knowing how those permissions got changed. I rebooted the system early on in the process as I kept seeing messages like this: 120114 9:39:04 [ERROR] Can't start server : Bind on unix socket: Permission denied 120114 9:39:04 [ERROR] Do you already have another mysqld server running on socket: /tmp/mysql.sock ? Those are rubbish as error messages as they don't say the file can't be created or give any indication of the actual problem. This is all more a problem for the mysql developers than FreeBSD but I am posting it to the list in case anyone else gets bitten by it. -- Paul Beard Are you trying to win an argument or solve a problem?
Re: Solution: mysqld fails to run, can't create/find mysql.sock
On Jan 14, 2012, at 11:15 AM, Chuck Swiger wrote: The meaning seems obvious enough; mysqld was unable to bind to the socket, which is what perror() meant with Permission denied: Really? I read this: 120114 9:39:04 [ERROR] Do you already have another mysqld server running on socket: /tmp/mysql.sock ? as there is an existing socket that seems to be in use: what's up with that? The message references a file that does not exist (but that mysql will cheerfully remove if found). There was no existing socket. Those two lines, taken together, tell me that a. mysql can't run without a socket and b. it thinks another process is running, bound to a socket that doesn't exist. Clear as mud. How about [ERROR] socket: /tmp/mysql.sock not found and/or [ERROR] socket:/tmp/mysql.sock could not be created perhaps with a helpful hint about permissions. If this was unusual, that would be one thing but I found quite a few references to the problem before I found the solution. Maybe it's a housekeeping thing but why would mysql need to destroy the file it uses for a socket and then recreate it when it could simply examine it and reuse it? Anyway, doesn't the mysql port want to keep the socket under /var/run/mysql/mysqld.sock or some such, to avoid issues with /tmp? Apparently not, as I commented out any reference to it in my.cnf and still saw the same messages about /tmp/mysql.sock. It seems to work if spelled out explicitly. -- Paul Beard Are you trying to win an argument or solve a problem?
Re: Solution: mysqld fails to run, can't create/find mysql.sock
On Jan 14, 2012, at 10:17 AM, Paul Beard wrote: I would be interested in knowing how those permissions got changed. Someone or something running as root changed them. I rebooted the system early on in the process as I kept seeing messages like this: 120114 9:39:04 [ERROR] Can't start server : Bind on unix socket: Permission denied 120114 9:39:04 [ERROR] Do you already have another mysqld server running on socket: /tmp/mysql.sock ? Those are rubbish as error messages as they don't say the file can't be created or give any indication of the actual problem. The meaning seems obvious enough; mysqld was unable to bind to the socket, which is what perror() meant with Permission denied: 13 EACCES Permission denied. An attempt was made to access a file in a way forbidden by its file access permissions. Either /tmp was unwritable for mysqld due to not having 1777 perms, or /tmp/mysql.sock probably already existed but was owned by root and not the user mysqld runs as. Anyway, doesn't the mysql port want to keep the socket under /var/run/mysql/mysqld.sock or some such, to avoid issues with /tmp? Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
database apps that ignore sockets? [was: Solution: mysqld fails to run, can't create/find mysql.sock]
On Jan 14, 2012, at 11:15 AM, Chuck Swiger wrote: Anyway, doesn't the mysql port want to keep the socket under /var/run/mysql/mysqld.sock or some such, to avoid issues with /tmp? Turns out some applications won't work if you move the socket if they are configured to access localhost. Seems like a misunderstanding of networking if you can specify a port number in a configuration file but the application looks to the filesystem for the socket. There is no way to specify a file location so it seems doomed to fail — as it did. The apps in question are net-mgmt/cacti and net-mgmt/cacti-spine. -- Paul Beard Are you trying to win an argument or solve a problem?
