Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal #101

Closed
opened 2020-02-12 12:21:09 +01:00 by rurus9 · 6 comments
rurus9 commented 2020-02-12 12:21:09 +01:00 (Migrated from github.com)

Describe the issue
Under stress glewlwyd docker container stop responding, sometimes it logs "Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal" (when I set DEBUG log level).
I observed this behavior in my kubernetes deployment, when number of connections with token request with ESTABLISHED status was ~40-50 (I checked with netstat inside running container, with simple script while true; do date; netstat -nt| awk '{ print $6 }' | grep -v Foreign | grep -v ^$ | sort | uniq -c; sleep 1; done

To Reproduce
Deploy glewlwyd in Kubernetes, generate > 50 connections to container with token request.

I discovered another way to to achieve this undesirable condition (maybe the reason is the same?):
a) start official docker image (I belive this is 2.1.1 vesion):
docker run --rm -it -p 4593:4593 babelouest/glewlwyd
b) configure oauth2 plugin, I set only "Name", "Display Name" as "oauth2", and add private and public key. I didn't configure any client or scope.
c) generate as much token request as you can. I use twice - on two terminals - that script:

while true; do
        echo "$INC $(date +%H.%M.%S)";
        curl -s --user no_user:NoPassword \
        --data-urlencode "grant_type=client_credentials" \
        --data-urlencode "scope=detection" \
        -H "Content-Type: application/x-www-form-urlencoded" \
        http://localhost:4593/api/oauth2/token 
        ((INC++))
done

After some time (less then minute) glewlwed is stucked, but container is still running - you can't get token or login to web interface.

Expected behavior
glewlwyd should handle greater load/more connections

System (please complete the following information):

  • OS/Environment [Debian bullseye, Ubuntu 18.04.2 LTS]
  • Browser used [curl 7.67.0]
  • Glewlwyd Version [2.1.1]
  • Source installation [official docker image]

Docker logs

2020-02-12T11:10:47 - Glewlwyd INFO: Starting Glewlwyd SSO authentication service
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermodldap.so - ldap
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermoddatabase.so - database
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermodhttp.so - http
2020-02-12T11:10:47 - Glewlwyd INFO: Loading client module /usr/lib/glewlwyd/client/libclientmoddatabase.so - database
2020-02-12T11:10:47 - Glewlwyd INFO: Loading client module /usr/lib/glewlwyd/client/libclientmodldap.so - ldap
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodotp.so - otp
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodhttp.so - http
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodcertificate.so - certificate
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodemail.so - email
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodwebauthn.so - webauthn
2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodpassword.so - retype-password
2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_oidc.so - oidc
2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_oauth2.so - oauth2-glewlwyd
2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_register.so - register
2020-02-12T11:10:47 - Glewlwyd INFO: Start glewlwyd on port 4593, prefix: api, secure: false, bind address: no
2020-02-12T11:12:44 - Glewlwyd INFO: Init plugin Glewlwyd Oauth2 'oauth2'
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoints with plugin prefix oauth2
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/auth/
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint POST api/oauth2/token/
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint * api/oauth2/profile/*
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/profile/
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/profile/token/
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint DELETE api/oauth2/profile/token/:token_hash
2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint * api/oauth2/profile/*
2020-02-12T11:13:24 - Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal
**Describe the issue** Under stress glewlwyd docker container stop responding, sometimes it logs "Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal" (when I set DEBUG log level). I observed this behavior in my kubernetes deployment, when number of connections with token request with ESTABLISHED status was ~40-50 (I checked with netstat inside running container, with simple script `while true; do date; netstat -nt| awk '{ print $6 }' | grep -v Foreign | grep -v ^$ | sort | uniq -c; sleep 1; done` **To Reproduce** Deploy glewlwyd in Kubernetes, generate > 50 connections to container with token request. I discovered another way to to achieve this undesirable condition (maybe the reason is the same?): a) start official docker image (I belive this is 2.1.1 vesion): `docker run --rm -it -p 4593:4593 babelouest/glewlwyd` b) configure oauth2 plugin, I set only "Name", "Display Name" as "oauth2", and add private and public key. I didn't configure any client or scope. c) generate as much token request as you can. I use twice - on two terminals - that script: ```INC=1 while true; do echo "$INC $(date +%H.%M.%S)"; curl -s --user no_user:NoPassword \ --data-urlencode "grant_type=client_credentials" \ --data-urlencode "scope=detection" \ -H "Content-Type: application/x-www-form-urlencoded" \ http://localhost:4593/api/oauth2/token ((INC++)) done ``` After some time (less then minute) glewlwed is stucked, but container is still running - you can't get token or login to web interface. **Expected behavior** glewlwyd should handle greater load/more connections **System (please complete the following information):** - OS/Environment [Debian bullseye, Ubuntu 18.04.2 LTS] - Browser used [curl 7.67.0] - Glewlwyd Version [2.1.1] - Source installation [official docker image] **Docker logs** ``` 2020-02-12T11:10:47 - Glewlwyd INFO: Starting Glewlwyd SSO authentication service 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermodldap.so - ldap 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermoddatabase.so - database 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user module /usr/lib/glewlwyd/user/libusermodhttp.so - http 2020-02-12T11:10:47 - Glewlwyd INFO: Loading client module /usr/lib/glewlwyd/client/libclientmoddatabase.so - database 2020-02-12T11:10:47 - Glewlwyd INFO: Loading client module /usr/lib/glewlwyd/client/libclientmodldap.so - ldap 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodotp.so - otp 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodhttp.so - http 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodcertificate.so - certificate 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodemail.so - email 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodwebauthn.so - webauthn 2020-02-12T11:10:47 - Glewlwyd INFO: Loading user auth scheme module /usr/lib/glewlwyd/scheme/libschememodpassword.so - retype-password 2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_oidc.so - oidc 2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_oauth2.so - oauth2-glewlwyd 2020-02-12T11:10:47 - Glewlwyd INFO: Loading plugin module /usr/lib/glewlwyd/plugin/libprotocol_register.so - register 2020-02-12T11:10:47 - Glewlwyd INFO: Start glewlwyd on port 4593, prefix: api, secure: false, bind address: no 2020-02-12T11:12:44 - Glewlwyd INFO: Init plugin Glewlwyd Oauth2 'oauth2' 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoints with plugin prefix oauth2 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/auth/ 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint POST api/oauth2/token/ 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint * api/oauth2/profile/* 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/profile/ 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint GET api/oauth2/profile/token/ 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint DELETE api/oauth2/profile/token/:token_hash 2020-02-12T11:12:44 - Glewlwyd INFO: Add endpoint * api/oauth2/profile/* 2020-02-12T11:13:24 - Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal ```
babelouest commented 2020-02-12 18:40:06 +01:00 (Migrated from github.com)

Hello @rurus9 ,

I've ran some tests to try to reproduce your problem but so far without success.

I've tried with the following parameters:

  • Using OAuth2 or OpenID Connect plugin
  • With a valid client_id/password or an invalid password
  • Using the official docker image or build and running from compiled source

Each combination of those parameters were tested, but I haven't been able to reproduce any problem you mention.

Although, my test script is executed from another machine than the one running Glewlwyd, because the test itself can affect the program tested in terms of performance.

To be sure, I ran tests using apache ab, using the same parameters combination as above with the compiled source instance, but not with the docker image.

Each tests were completed successfully (i.e. no segfault),

Here is the type of ab command I use:

$ ab -A client_test:password -p post.txt -T application/x-www-form-urlencoded -c 10 -n 200 http://host_test:4593/api/glwd/token/

The file post.txt contains the following:

grant_type=client_credentials&scope=g_profile

And the result looks like this:

user@host:~ $ ab -A client_test:password -p post.txt -T application/x-www-form-urlencoded -c 10 -n 2000 http://host_test:4593/api/glwd/token/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking host_test (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Completed 2000 requests
Finished 2000 requests


Server Software:
Server Hostname:        host_test
Server Port:            4593

Document Path:          /api/glwd/token/
Document Length:        1019 bytes

Concurrency Level:      10
Time taken for tests:   98.160 seconds
Complete requests:      2000
Failed requests:        0
Total transferred:      2488000 bytes
Total body sent:        524000
HTML transferred:       2038000 bytes
Requests per second:    20.37 [#/sec] (mean)
Time per request:       490.800 [ms] (mean)
Time per request:       49.080 [ms] (mean, across all concurrent requests)
Transfer rate:          24.75 [Kbytes/sec] received
                        5.21 kb/s sent
                        29.97 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0      10
Processing:   147  488 252.7    397    1552
Waiting:      146  487 252.7    397    1552
Total:        147  488 252.7    397    1553

Percentage of the requests served within a certain time (ms)
  50%    397
  66%    440
  75%    497
  80%    592
  90%    935
  95%   1090
  98%   1199
  99%   1273
 100%   1553 (longest request)

I suggest you check the configuration in your infrastructure running the docker images, but so far I couldn't find any problem in Glewlwyd itself that could lead in segfault in case of heavy load.

Hello @rurus9 , I've ran some tests to try to reproduce your problem but so far without success. I've tried with the following parameters: - Using OAuth2 or OpenID Connect plugin - With a valid client_id/password or an invalid password - Using the official docker image or build and running from compiled source Each combination of those parameters were tested, but I haven't been able to reproduce any problem you mention. Although, my test script is executed from another machine than the one running Glewlwyd, because the test itself can affect the program tested in terms of performance. To be sure, I ran tests using [apache ab](https://httpd.apache.org/docs/2.4/en/programs/ab.html), using the same parameters combination as above with the compiled source instance, but not with the docker image. Each tests were completed successfully (i.e. no segfault), Here is the type of ab command I use: ```shell $ ab -A client_test:password -p post.txt -T application/x-www-form-urlencoded -c 10 -n 200 http://host_test:4593/api/glwd/token/ ``` The file post.txt contains the following: ``` grant_type=client_credentials&scope=g_profile ``` And the result looks like this: ``` user@host:~ $ ab -A client_test:password -p post.txt -T application/x-www-form-urlencoded -c 10 -n 2000 http://host_test:4593/api/glwd/token/ This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking host_test (be patient) Completed 200 requests Completed 400 requests Completed 600 requests Completed 800 requests Completed 1000 requests Completed 1200 requests Completed 1400 requests Completed 1600 requests Completed 1800 requests Completed 2000 requests Finished 2000 requests Server Software: Server Hostname: host_test Server Port: 4593 Document Path: /api/glwd/token/ Document Length: 1019 bytes Concurrency Level: 10 Time taken for tests: 98.160 seconds Complete requests: 2000 Failed requests: 0 Total transferred: 2488000 bytes Total body sent: 524000 HTML transferred: 2038000 bytes Requests per second: 20.37 [#/sec] (mean) Time per request: 490.800 [ms] (mean) Time per request: 49.080 [ms] (mean, across all concurrent requests) Transfer rate: 24.75 [Kbytes/sec] received 5.21 kb/s sent 29.97 kb/s total Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 10 Processing: 147 488 252.7 397 1552 Waiting: 146 487 252.7 397 1552 Total: 147 488 252.7 397 1553 Percentage of the requests served within a certain time (ms) 50% 397 66% 440 75% 497 80% 592 90% 935 95% 1090 98% 1199 99% 1273 100% 1553 (longest request) ``` I suggest you check the configuration in your infrastructure running the docker images, but so far I couldn't find any problem in Glewlwyd itself that could lead in segfault in case of heavy load.
rurus9 commented 2020-02-13 12:31:51 +01:00 (Migrated from github.com)

Today we tested glewlwyd official docker image on few Linux servers and workstations, every time a large number of requests caused the application to hang.
This time we used ab too, with parameters like yours:

ab -A noClient:noPassword -p post.txt -T application/x-www-form-urlencoded -c 10 -n 200 http://remote.host.IP:4593/api/glwd/token/

post.txt:

grant_type=client_credentials&scope=g_profile

We tested this way
1. First we started docker image:
docker run -it -p 4593:4593 babelouest/glewlwyd
2. Then we used from another station ab - without any glewlwyd configuration. Every test was fine:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.186.40 (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests


Server Software:        
Server Hostname:        192.168.186.40
Server Port:            4593

Document Path:          /api/glwd/token/
Document Length:        80 bytes

Concurrency Level:      10
Time taken for tests:   0.089 seconds
Complete requests:      200
Failed requests:        0
Non-2xx responses:      200
Total transferred:      62000 bytes
Total body sent:        52800
HTML transferred:       16000 bytes
Requests per second:    2258.76 [#/sec] (mean)
Time per request:       4.427 [ms] (mean)
Time per request:       0.443 [ms] (mean, across all concurrent requests)
Transfer rate:          683.81 [Kbytes/sec] received
                        582.34 kb/s sent
                        1266.14 kb/s total

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:     1    4   3.0      3      22
Waiting:        1    4   2.9      3      22
Total:          1    4   3.1      3      22

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      4
  75%      5
  80%      6
  90%     10
  95%     11
  98%     13
  99%     14
 100%     22 (longest request)

3. Then we only added oauth2 plugin (we set: "Name" and "Display Name": glwd, Tokens signature: JWT type, Key size: 512 bits and "Secret key" and "Public key").
Now, when we ran ab, glewlwyd stucked... Not every time with Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal, but whenever you can't get web login interface and working token endpoint.
ab logs:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.186.40 (be patient)
apr_pollset_poll: The timeout specified has expired (70007)
Total of 1 requests completed

Although glewlwyd does not work, docker image is still running, we can log into with docker exec -it CONTAINER_ID bash and execute commands:

bash-5.0# ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 {entrypoint.sh} /bin/bash /entrypoint.sh
    8 root      0:01 glewlwyd --config-file=/etc/glewlwyd/glewlwyd.conf -mconsole
 2031 root      0:00 bash
 2038 root      0:00 ps aux
bash-5.0# netstat 
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp      265      0 45ece1f8326d:4593       172.18.0.1:58524        CLOSE_WAIT  
tcp      265      0 45ece1f8326d:4593       172.18.0.1:58522        CLOSE_WAIT  
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58516        CLOSE_WAIT  
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58502        CLOSE_WAIT  
tcp        0      0 45ece1f8326d:4593       172.18.0.1:58460        ESTABLISHED 
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58514        CLOSE_WAIT  
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58494        CLOSE_WAIT  
tcp      265      0 45ece1f8326d:4593       172.18.0.1:58520        CLOSE_WAIT  
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58512        CLOSE_WAIT  
tcp        1      0 45ece1f8326d:4593       172.18.0.1:58518        CLOSE_WAIT  
tcp      265      0 45ece1f8326d:4593       172.18.0.1:58526        CLOSE_WAIT  
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags       Type       State         I-Node Path

How can I help debug this strange docker image behavior?

Today we tested glewlwyd official docker image on few Linux servers and workstations, every time a large number of requests caused the application to hang. This time we used ab too, with parameters like yours: ``` ab -A noClient:noPassword -p post.txt -T application/x-www-form-urlencoded -c 10 -n 200 http://remote.host.IP:4593/api/glwd/token/ ``` post.txt: ``` grant_type=client_credentials&scope=g_profile ``` We tested this way **1. First we started docker image:** `docker run -it -p 4593:4593 babelouest/glewlwyd` **2. Then we used from another station `ab` - without any glewlwyd configuration.** Every test was fine: ``` This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.186.40 (be patient) Completed 100 requests Completed 200 requests Finished 200 requests Server Software: Server Hostname: 192.168.186.40 Server Port: 4593 Document Path: /api/glwd/token/ Document Length: 80 bytes Concurrency Level: 10 Time taken for tests: 0.089 seconds Complete requests: 200 Failed requests: 0 Non-2xx responses: 200 Total transferred: 62000 bytes Total body sent: 52800 HTML transferred: 16000 bytes Requests per second: 2258.76 [#/sec] (mean) Time per request: 4.427 [ms] (mean) Time per request: 0.443 [ms] (mean, across all concurrent requests) Transfer rate: 683.81 [Kbytes/sec] received 582.34 kb/s sent 1266.14 kb/s total Connection Times (ms) min mean[+/-sd] median max Connect: 0 0 0.2 0 1 Processing: 1 4 3.0 3 22 Waiting: 1 4 2.9 3 22 Total: 1 4 3.1 3 22 Percentage of the requests served within a certain time (ms) 50% 3 66% 4 75% 5 80% 6 90% 10 95% 11 98% 13 99% 14 100% 22 (longest request) ``` **3. Then we only added oauth2 plugin** (we set: "Name" and "Display Name": `glwd`, Tokens signature: `JWT type`, Key size: `512 bits` and "Secret key" and "Public key"). Now, when we ran ab, glewlwyd stucked... Not every time with `Glewlwyd ERROR: Glewlwyd - Received segmentation fault signal`, but whenever you can't get web login interface and working token endpoint. ab logs: ``` This is ApacheBench, Version 2.3 <$Revision: 1843412 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 192.168.186.40 (be patient) apr_pollset_poll: The timeout specified has expired (70007) Total of 1 requests completed ``` Although glewlwyd does not work, docker image is still running, we can log into with `docker exec -it CONTAINER_ID bash` and execute commands: ``` bash-5.0# ps aux PID USER TIME COMMAND 1 root 0:00 {entrypoint.sh} /bin/bash /entrypoint.sh 8 root 0:01 glewlwyd --config-file=/etc/glewlwyd/glewlwyd.conf -mconsole 2031 root 0:00 bash 2038 root 0:00 ps aux bash-5.0# netstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 265 0 45ece1f8326d:4593 172.18.0.1:58524 CLOSE_WAIT tcp 265 0 45ece1f8326d:4593 172.18.0.1:58522 CLOSE_WAIT tcp 1 0 45ece1f8326d:4593 172.18.0.1:58516 CLOSE_WAIT tcp 1 0 45ece1f8326d:4593 172.18.0.1:58502 CLOSE_WAIT tcp 0 0 45ece1f8326d:4593 172.18.0.1:58460 ESTABLISHED tcp 1 0 45ece1f8326d:4593 172.18.0.1:58514 CLOSE_WAIT tcp 1 0 45ece1f8326d:4593 172.18.0.1:58494 CLOSE_WAIT tcp 265 0 45ece1f8326d:4593 172.18.0.1:58520 CLOSE_WAIT tcp 1 0 45ece1f8326d:4593 172.18.0.1:58512 CLOSE_WAIT tcp 1 0 45ece1f8326d:4593 172.18.0.1:58518 CLOSE_WAIT tcp 265 0 45ece1f8326d:4593 172.18.0.1:58526 CLOSE_WAIT Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node Path ``` How can I help debug this strange docker image behavior?
babelouest commented 2020-02-13 19:24:34 +01:00 (Migrated from github.com)

Hello @rurus9 ,

So I could finally reproduce the crash with the docker image.
For what I've seen, the problem lies in Alpine Linux, and more specifically with the architecture x86_64, because I've run heavy load tests with the following docker platforms:

  • Alpine Linux 3.11 x86_64
  • Alpine Linux 3.11 armv71 (Raspberry pi 4)
  • Debian Buster x86_64
  • Ubuntu LTS 18.04 x86_64
  • Ubuntu Rolling 19.10 x86_64
  • Debian Buster armv71 (Raspberry pi 4)

The only platform with the crash problem is Alpine Linux 3.11 x86_64, which unfortunately is the platform underneath Glewlwyd docker image.

I'm gonna ask to the Alpine team if there's a way to fix that, it may be a config problem or a bug on their side, but I'll also provide at least 2 other docker images for Glewlwyd: one with Debian Buster and one with Ubuntu LTS. And until the problem in Alpine Linux is fixed (if it can be), I suggest to use the other images if performance is an issue.

The new docker images will be available soon.

Hello @rurus9 , So I could finally reproduce the crash with the docker image. For what I've seen, the problem lies in Alpine Linux, and more specifically with the architecture x86_64, because I've run heavy load tests with the following docker platforms: - Alpine Linux 3.11 x86_64 - Alpine Linux 3.11 armv71 (Raspberry pi 4) - Debian Buster x86_64 - Ubuntu LTS 18.04 x86_64 - Ubuntu Rolling 19.10 x86_64 - Debian Buster armv71 (Raspberry pi 4) The only platform with the crash problem is `Alpine Linux 3.11 x86_64`, which unfortunately is the platform underneath Glewlwyd docker image. I'm gonna ask to the Alpine team if there's a way to fix that, it may be a config problem or a bug on their side, but I'll also provide at least 2 other docker images for Glewlwyd: one with Debian Buster and one with Ubuntu LTS. And until the problem in Alpine Linux is fixed (if it can be), I suggest to use the other images if performance is an issue. The new docker images will be available soon.
rurus9 commented 2020-02-14 08:12:16 +01:00 (Migrated from github.com)

@babelouest - this is both good and bad news.
Could you share your Dockerfile for Debian [x86_64] flavor?

@babelouest - this is both good and bad news. Could you share your Dockerfile for Debian [x86_64] flavor?
babelouest commented 2020-02-16 14:56:28 +01:00 (Migrated from github.com)

Hello @rurus9 ,

Can you try to build the docker image with the current master branch? It looks like github.com/babelouest/glewlwyd@d5948972af fixed it for us.

Hello @rurus9 , Can you try to build the docker image with the current master branch? It looks like https://github.com/babelouest/glewlwyd/commit/d5948972af48e7828260203acf1875766f50b1be fixed it for us.
rurus9 commented 2020-02-17 10:31:25 +01:00 (Migrated from github.com)

I was testing today and it's ok now.
Thank you.

I was testing today and it's ok now. Thank you.
This discussion has been locked. Commenting is limited to contributors.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
KittenSquad/glewlwyd#101
No description provided.