[MXS-3886] Hang in RoutingWorker::execute_concurrently semaphore.hh:146 Created: 2021-11-19  Updated: 2022-07-06  Resolved: 2022-01-28

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 6.1.4
Fix Version/s: 2.5.19, 6.2.2

Type: Bug Priority: Major
Reporter: Maria M Pflaum Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOs 7


Issue Links:
Blocks
blocks MXS-3775 Hang in RoutingWorker::execute_concur... Closed
Sprint: MXS-SPRINT-148, MXS-SPRINT-149

 Description   

2021-11-19 16:32:23   alert  : (sigfatal_handler): MaxScale 6.1.4 received fatal signal 6. Commit ID: d358b90fc6c45c1875b5e32133b19b80bddf117d System name: Linux Release string: NAME="CentOS Linux"
2021-11-19 16:32:23   alert  : (sigfatal_handler): Statement currently being classified: none/unknown
alert  :   /lib64/libpthread.so.0(+0xdb3b): sem_wait.c:?
  /lib64/libpthread.so.0(+0xdbcf): sem_wait.c:?
  /lib64/libpthread.so.0(sem_wait+0x2b): ??:0
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN8maxscale13RoutingWorker20execute_concurrentlyERKSt8functionIFvvEE+0x52): maxutils/maxbase/include/maxbase/semaphore.hh:146
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(+0x19d5da): /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/std_function.h:275
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker14handle_messageERNS_12MessageQueueERKNS_19MessageQueueMessageE+0x119): maxutils/maxbase/src/worker.cc:478
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase12MessageQueue18handle_poll_eventsEPNS_6WorkerEj+0x98): maxutils/maxbase/src/messagequeue.cc:307
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker15poll_waiteventsEv+0x1e3): maxutils/maxbase/src/worker.cc:865
  /usr/lib64/maxscale/libmaxscale-common.so.1.0.0(_ZN7maxbase6Worker3runEPNS_9SemaphoreE+0x4f): maxutils/maxbase/src/worker.cc:562
  /usr/bin/maxscale(main+0x1fd6): server/core/gateway.cc:2213
  /lib64/libc.so.6(__libc_start_main+0xf5): ??:?
  /usr/bin/maxscale(): ??:?



 Comments   
Comment by markus makela [ 2022-01-21 ]

This seems to have happened due to a reverse name lookup that took too long. This is sort of an expected problem and unconditionally leaving the feature on isn't good as exactly what happened here can happen. As a first step towards solving it, we can make it so that both the normal hostname-to-IP name lookup and the IP-to-hostname reverse name lookup are configurable.

Comment by markus makela [ 2022-01-28 ]

Added the skip_name_resolve option to MaxScale which allows client hostname resolution to be skipped. With skip_name_resolve=true, MaxScale will not perform a reverse DNS lookup on the client's IP even if a grant with a hostname that could potentially match exists. This is very close to how the skip_name_resolve parameter works in MariaDB except that MaxScale will not prevent such users from being created.

Generated at Thu Feb 08 04:24:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.