MySQL no longer starting “An attempt was made to access a socket in a way forbidden by its access permissions.” (Windows 10)

MySQLstartupwindows

I don't think this is another "some other process is using port 3306 rtfm" kinda question.

I have been running MySQL 8.0.x fine for a couple of months on Windows 10 for some local python development. As of this week it refuses to start (don't know the exact date of when it started, but logs say it was still running 30/10/2020).

2020-11-07T10:57:43.452460Z 0 [System] [MY-010910] [Server] C:\tools\mysql\current\bin\mysqld: Shutdown complete (mysqld 8.0.22)  MySQL Community Server - GPL.
2020-11-07T11:01:21.048896Z 0 [System] [MY-010116] [Server] C:\tools\mysql\current\bin\mysqld (mysqld 8.0.22) starting as process 3480
2020-11-07T11:01:21.071269Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-11-07T11:01:21.618118Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2020-11-07T11:01:22.095397Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060
2020-11-07T11:01:22.174810Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2020-11-07T11:01:22.175307Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2020-11-07T11:01:22.177656Z 0 [ERROR] [MY-010262] [Server] Can't start server: Bind on TCP/IP port: An attempt was made to access a socket in a way forbidden by its access permissions.

At first I thought maybe the 3306 port was in used, but that was not the case. Did a reboot to be sure. Stopped Docker. Checked if the exception was still present in the windows firewall. All good.
Tried port 3307 just to see what happened. Disabled Windows Defender. Same result. So my feeling is this might be caused by some Windows Update or changed security setting.

netstat shows no process listening to port 3306:

netstat -ano | find /i "3306"
<no output>

I did google a lot, but couldn't really find anything beyond SELinux or Antivirus preventing stuff.

Any pointers. Probably Windows Defender / Firewall, but don't know what setting to adjust. Mysql exception rule is in place:

Valentijn

Best Answer

Found the issue. Even though I rebooted (turned off, turned on), my ethernet connection (via dell dock) was not active. So only wifi was active and apparently windows prevents services from listening to ports on that. Even though there's an exception present for public networks in the firewall. Anyway, after disconnecting and reconnecting the ethernet cable it started working again.

Related Solutions

Thesql no longer defaulting to /tmp/thesql.sock

The MySQL documentation states that the default path to mysql.sock is /var/lib/mysql/ on RPM distributions. The path is set at compile-time depending on the target OS and can be overridden by configuration or command line, so for CentOS the behavior you are seeing is correct.

This means that the socket path must have originally been set to /tmp by some other mechanism. There are several places this could have been done; likely in the init script /etc/init.d/mysql.server (to set socket=/tmp/mysql.sock on the command line - this can be done in an init script even though it is unsupported) or a local options file. See this page in the documentation for MySQL's precedence order when processing startup options. Entries listed later in the table will override the preceding ones.

It probably isn't possible to trace the sequence of events leading up to the socket path change, but fortunately you can change it via ~/.my.cnf, the user-specific option file.

Mysql – Error 1236 ‘Found old binary log without GTIDs’ after master restart

Something is not right about your process.

Usually, when I see error 1236, such the following I used in my old post How can you monitor if MySQL binlog files get corrupted?

[ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236).
[ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236
111014 20:25:48 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.001067', position 183468345.

here was the situation: When doing MySQL Replication without GTID, the IO Thread examines the position from the latest Master binlog. If Read_Master_Log_Pos is bigger than the actual filesize of the binlog, you get error 1236.

When doing MySQL Replication with GTID, the situation is somewhat similar. The IO Thread is looking for some kind of closure with regard to the GTID it was last using. When you restarted MySQL on the Master, you closed the last binlog on the Master and opened a new binlog upon startup. The IO Thread on the Slave was still active. Thus, the same error number is coming up.

The next time you restart a Master, remember the Slaves are active.

The slave should have reconnected after a minute, but that is not happening for you.

To play it safe, you should do the following

On the Slave, STOP SLAVE;
On the Master, service mysql restart
On the Slave, START SLAVE;

You should not have to do this. As an alternative, try setting up replication with heartbeat set at one tenth of a second:

CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 100;

This should make the IO Thread on the Slave a little more sensitive

Best Answer

Related Solutions

Thesql no longer defaulting to /tmp/thesql.sock

Mysql – Error 1236 ‘Found old binary log without GTIDs’ after master restart

Related Question