Bug #1720 | Slave Start cause Mysql server to crash | ||
---|---|---|---|
Submitted: | 30 Oct 2003 19:42 | Modified: | 17 Nov 2003 6:23 |
Reporter: | Jack Chan | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S1 (Critical) |
Version: | 3.23.58 | OS: | Windows (Windows 2000) |
Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[30 Oct 2003 19:42]
Jack Chan
[30 Oct 2003 20:36]
MySQL Verification Team
You are mentioned that both servers are started as service on both machines. If you had issued the install of the service using the default command for to install the service: e.g.: mysqld-nt --install; that means that the service is owned by the local system account and Windows doesn't permits that the local system account should be authenticated against a remote machine (mysqld has a piece of code which verify this). For to resolve this issue you have the below options: 1- Change using the Service Control Manager (SCM) the system local account for another user account (the user should need the administrator privileges or the ones enough for to performer write/read operation) on both machines. In another words the replication needs the mysqld servers and Windows privileges for. 2- You can avoid this starting both servers as standalone not as service. 3- If you resolve this issue with the above work around, also this report should be considered as a bug because the correct mysqld action should be a message error indicating a denied OS write/read operation instead of a crash. For this reason I am assigning this bug for Guilhem.
[3 Nov 2003 13:53]
MySQL Verification Team
Yes I was able to repeat the server slave crash trying to connect with a master running on Win2000. At the bottom the stack trace. Guilhem: a 4.0.16 server doesn't crash: E:\mysql\bin>mysqld --standalone --console mysqld: ready for connections. Version: '4.0.16-max-debug-log' socket: '' port: 3306 031103 19:44:27 Slave I/O thread: connected to master 'repl@192.168.0.77:3306', replication started in log 'FIRST' at position 4 /thr_alarm.c void thr_end_alarm(thr_alarm_t *alrm_ptr) { thr_alarm_t alrm= *alrm_ptr; if (alrm->crono) ^^^^^^^^^^^^^^^^^^^^ { KillTimer(NULL, alrm->crono); alrm->crono = 0; } } > mysqld.exe!thr_end_alarm(st_thr_alarm_entry * * alrm_ptr=0x01cff63c) Line 641 + 0x3 C mysqld.exe!mc_mysql_connect(st_mysql * mysql=0x0044a5f3, const char * host=0x00b6d2a8, const char * user=0x006c4810, const char * passwd=0x006c484d, const char * db=0x006c485e, unsigned int port=0, const char * unix_socket=0x00000cea, unsigned int client_flag=0) Line 602 + 0xc C++ mysqld.exe!safe_connect(THD * thd=0x00448d3d, st_mysql * mysql=0x00b3f868, st_master_info * mi=0x00b6d2a8) Line 1569 + 0x43 C++ mysqld.exe!handle_slave(void * arg=0x004b7ac6) Line 1364 + 0x10 C++ mysqld.exe!pthread_start(void * param=0x00b6df98) Line 64 + 0x7 C mysqld.exe!_threadstart(void * ptd=0x00b769d8) Line 173 + 0xd C kernel32.dll!77e6d33b()
[17 Nov 2003 6:23]
Guilhem Bichot
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release. If necessary, you can access the source repository and build the latest available version, including the bugfix, yourself. More information about accessing the source trees is available at http://www.mysql.com/doc/en/Installing_source_tree.html ChangeSet@1.1422.1.1, 2003-11-17 12:59:07+02:00, monty@mashka.mysql.fi