Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
5.5.28a-galera
Description
We have a persistent buildbot failure:
http://buildbot.askmonty.org/buildbot/builders/kvm-rpm-centos5-amd64/builds/1981/steps/test/logs/stdio
It is reproducible on a child of the same VM (or of the sibling -build VM).
If I build server exactly as the buildbot test does, and install the resulting RPM file, I get the same problem: on an attempt to set wsrep_provider the server complains
130303 23:00:28 [ERROR] WSREP: Process completed with error: /sbin/ifconfig | grep -E '^[[:space:]]+inet addr:' | grep -m1 -v 'inet addr:127'
|
| sed 's/:/ /' | awk '{ print $3 }': 2 (No such file or directory)
|
130303 23:00:28 [Warning] WSREP: Failed to guess base node address. Set it explicitly via wsrep_node_address.
|
130303 23:00:28 [Warning] WSREP: Guessing address for incoming client connections failed. Try setting wsrep_node_incoming_address explicitly.
|
130303 23:00:28 [Warning] WSREP: Could not open saved state file for reading: /var/lib/mysql//grastate.dat
|
130303 23:00:28 [Note] WSREP: Found saved state: 00000000-0000-0000-0000-000000000000:-1
|
130303 23:00:28 [Note] WSREP: Preallocating 134219048/134219048 bytes in '/var/lib/mysql//galera.cache'...
|
130303 23:00:28 [Note] WSREP: Passing config to GCS: base_port = 4567; cert.log_conflicts = no; gcache.dir = /var/lib/mysql/; gcache.keep_page
|
s_size = 0; gcache.mem_size = 0; gcache.name = /var/lib/mysql//galera.cache; gcache.page_size = 128M; gcache.size = 128M; gcs.fc_debug = 0; gc
|
s.fc_factor = 1; gcs.fc_limit = 16; gcs.fc_master_slave = NO; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 92
|
23372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = NO; replicator.causal_read_timeout = PT30S; replicator.commit_order = 3
|
terminate called after throwing an instance of 'gu::NotSet'
|
and immediately crashes:
[ERROR] mysqld got signal 6 ;
|
...
|
Thread pointer: 0x0x77e0270
|
Attempting backtrace. You can use the following information to find out
|
where mysqld died. If you see no messages after this, something went
|
terribly wrong...
|
stack_bottom = 0x4aebb0a8 thread_stack 0x48000
|
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0xab7e3e]
|
/usr/sbin/mysqld(handle_fatal_signal+0x44c)[0x6ef08c]
|
/lib64/libpthread.so.0[0x3bed60e7c0]
|
/lib64/libc.so.6(gsignal+0x35)[0x3bece30265]
|
/lib64/libc.so.6(abort+0x110)[0x3bece31d10]
|
/usr/lib64/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x114)[0x3bef2bec44]
|
/usr/lib64/libstdc++.so.6[0x3bef2bcdb6]
|
/usr/lib64/libstdc++.so.6[0x3bef2bcde3]
|
/usr/lib64/libstdc++.so.6[0x3bef2bceca]
|
/usr/lib64/galera/libgalera_smm.so(_ZNK2gu3URI8get_hostEv+0x38)[0x2aaabb589878]
|
[0x7899eb0]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7879368): set global wsrep_provider="/usr/lib64/galera/libgalera_smm.so"
|
|
|
Connection ID (thread ID): 1
|
Status: NOT_KILLED
|
But if I take mysqld binary from the same build and put it into /usr/sbin/ instead of the installed mysqld, there are no complaints about IP search, and no crash.
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
This is a configuration problem, caused by SELinux being enabled by default.
While the limitation has been mentioned in Galera FAQ (http://www.codership.com/wiki/doku.php?id=faq#qnothing_works_damnit), in this case the connection is very non-obvious for a user, it needs to be documented better.
It should go to FAQ with the explicit error message and explanation, so it could be searchable when users get stuck with the problem.
Please treat it as a documentation request, unless it can be handled better on the server side (e.g. produce a more meaningful error).
I've been running tests in order to find the reason of the difference, but no luck so far.