Hi everyone,
I proceeded as Antoine proposed and set "ARG ALPINE_BASE_IMAGE=3.18" in staging/1.5.5 Dockerfile.
The build worked and I was able to start the guacd container from this image. I tried more than 100 consecutive reconnects to an RDP session without the issue appearing.
So, it looks good to me. Can anyone confirm?
Infos on my docker-host:
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
Kernel 5.15.0-92-generic
Docker version 25.0.3, build 4debf41
Thanks to everyone working on this.
Best wishes
Michael
Gesendet: Freitag, 09. Februar 2024 um 09:00 Uhr
Von: "Antoine Besnier" <[email protected]>
An: "[email protected]" <[email protected]>
Betreff: Re: Aw: Re: Major bug message log in guacd 1.5.4
Von: "Antoine Besnier" <[email protected]>
An: "[email protected]" <[email protected]>
Betreff: Re: Aw: Re: Major bug message log in guacd 1.5.4
Hi,
On Alpine, openssl1.1-compat-dev is available for 3.17, 3.18 and Edge, but not 3.19 (which is the version for the 'latest' tag). You could try by changing the version of Alpine.
Cheers
Antoine
Le vendredi 9 février 2024 à 07:35:42 UTC+1, michael böhm <[email protected]> a écrit :
Hi everyone
I'd gladly test in our environment. However, the docker build does not work for me:
/tmp/guacamole-server ‹staging/1.5.5› » git checkout staging/1.5.5 1 ↵
Switched to branch 'staging/1.5.5'
Your branch is up to date with 'origin/staging/1.5.5'.
/tmp/guacamole-server ‹staging/1.5.5› » docker build -t guac_test .
[+] Building 0.9s (6/13) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 6.10kB 0.0s
=> [internal] load metadata for docker.io/library/alpine:latest 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 681B 0.0s
=> CACHED [builder 1/5] FROM docker.io/library/alpine:latest 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 28.84kB 0.0s
=> ERROR [builder 2/5] RUN apk add --no-cache autoconf automake build-base cairo-dev cmake git 0.8s
------
> [builder 2/5] RUN apk add --no-cache autoconf automake build-base cairo-dev cmake git grep libjpeg-turbo-dev libpng-dev libtool libwebp-dev make openssl1.1-compat-dev pango-dev pulseaudio-dev util-linux-dev:
0.285 fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
0.475 fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
0.718 ERROR: unable to select packages:
0.718 openssl1.1-compat-dev (no such package):
0.718 required by: world[openssl1.1-compat-dev]
------
Dockerfile:29
--------------------
28 | # Install build dependencies
29 | >>> RUN apk add --no-cache \
30 | >>> autoconf \
31 | >>> automake \
32 | >>> build-base \
33 | >>> cairo-dev \
34 | >>> cmake \
35 | >>> git \
36 | >>> grep \
37 | >>> libjpeg-turbo-dev \
38 | >>> libpng-dev \
39 | >>> libtool \
40 | >>> libwebp-dev \
41 | >>> make \
42 | >>> openssl1.1-compat-dev \
43 | >>> pango-dev \
44 | >>> pulseaudio-dev \
45 | >>> util-linux-dev
46 |
--------------------
ERROR: failed to solve: process "/bin/sh -c apk add --no-cache autoconf automake build-base cairo-dev cmake git grep libjpeg-turbo-dev libpng-dev libtool libwebp-dev make openssl1.1-compat-dev pango-dev pulseaudio-dev util-linux-dev" did not complete successfully: exit code: 1
Switched to branch 'staging/1.5.5'
Your branch is up to date with 'origin/staging/1.5.5'.
/tmp/guacamole-server ‹staging/1.5.5› » docker build -t guac_test .
[+] Building 0.9s (6/13) docker:default
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 6.10kB 0.0s
=> [internal] load metadata for docker.io/library/alpine:latest 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 681B 0.0s
=> CACHED [builder 1/5] FROM docker.io/library/alpine:latest 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 28.84kB 0.0s
=> ERROR [builder 2/5] RUN apk add --no-cache autoconf automake build-base cairo-dev cmake git 0.8s
------
> [builder 2/5] RUN apk add --no-cache autoconf automake build-base cairo-dev cmake git grep libjpeg-turbo-dev libpng-dev libtool libwebp-dev make openssl1.1-compat-dev pango-dev pulseaudio-dev util-linux-dev:
0.285 fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
0.475 fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
0.718 ERROR: unable to select packages:
0.718 openssl1.1-compat-dev (no such package):
0.718 required by: world[openssl1.1-compat-dev]
------
Dockerfile:29
--------------------
28 | # Install build dependencies
29 | >>> RUN apk add --no-cache \
30 | >>> autoconf \
31 | >>> automake \
32 | >>> build-base \
33 | >>> cairo-dev \
34 | >>> cmake \
35 | >>> git \
36 | >>> grep \
37 | >>> libjpeg-turbo-dev \
38 | >>> libpng-dev \
39 | >>> libtool \
40 | >>> libwebp-dev \
41 | >>> make \
42 | >>> openssl1.1-compat-dev \
43 | >>> pango-dev \
44 | >>> pulseaudio-dev \
45 | >>> util-linux-dev
46 |
--------------------
ERROR: failed to solve: process "/bin/sh -c apk add --no-cache autoconf automake build-base cairo-dev cmake git grep libjpeg-turbo-dev libpng-dev libtool libwebp-dev make openssl1.1-compat-dev pango-dev pulseaudio-dev util-linux-dev" did not complete successfully: exit code: 1
It seems that "openssl1.1-compat-dev" is not present in base image alpine:latest's repositories. Am I doing something wrong? On the master branch I can build the image just fine.
Thanks and best wishes
Michael
Gesendet: Freitag, 09. Februar 2024 um 02:59 Uhr
Von: "Michael Jumper" <[email protected]>
An: [email protected]
Betreff: Re: Major bug message log in guacd 1.5.4
Von: "Michael Jumper" <[email protected]>
An: [email protected]
Betreff: Re: Major bug message log in guacd 1.5.4
On 2/7/24 05:24, Nick Couchman wrote:
> On Wed, Feb 7, 2024 at 6:40 AM Yannick Martin
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello
>
> About pthread_keys leak, I wonder if
> https://github.com/apache/guacamole-server/blob/master/src/libguac/client.c#L299 <https://github.com/apache/guacamole-server/blob/master/src/libguac/client.c#L299>
> and L300 is not a duplicate call of those done in:
> guac_rwlock_init(&(client->__users_lock));
> guac_rwlock_init(&(client->__pending_users_lock));
>
> which call pthread_key_create too =>
> https://github.com/apache/guacamole-server/blob/master/src/libguac/rwlock.c#L52 <https://github.com/apache/guacamole-server/blob/master/src/libguac/rwlock.c#L52>
>
>
> Two issues with this:
> * I'm not sure that duplicating a call to pthread_key_create()
> would/should result in the behavior we're seeing - where TLS-based
> connections fail after a certain, relatively well-defined number (58-60).
> * This also would not explain why this only occurs in certain
> situations, on certain platforms - that is, the same exact libguac code
> running on EL7 (RHEL, CentOS, etc.) does not result in the resource
> leak, whereas it does on some other set of platforms (Debian, Alpine,
> EulerOS). Unless the pthread library has been changed substantially
> between those versions to not clean up after itself?
>
This *might* now be fixed on master and staging/1.5.5, if folks want to
take a look. The issue does appear to be have been the duplicate
pthread_key_create() calls noted above (pending confirmation with testing).
If this is the cause, it's still unclear why the behavior varies between
platforms. It might be a matter of varying implementations, different
resource limits, or something else platform-specific.
- Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
> On Wed, Feb 7, 2024 at 6:40 AM Yannick Martin
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello
>
> About pthread_keys leak, I wonder if
> https://github.com/apache/guacamole-server/blob/master/src/libguac/client.c#L299 <https://github.com/apache/guacamole-server/blob/master/src/libguac/client.c#L299>
> and L300 is not a duplicate call of those done in:
> guac_rwlock_init(&(client->__users_lock));
> guac_rwlock_init(&(client->__pending_users_lock));
>
> which call pthread_key_create too =>
> https://github.com/apache/guacamole-server/blob/master/src/libguac/rwlock.c#L52 <https://github.com/apache/guacamole-server/blob/master/src/libguac/rwlock.c#L52>
>
>
> Two issues with this:
> * I'm not sure that duplicating a call to pthread_key_create()
> would/should result in the behavior we're seeing - where TLS-based
> connections fail after a certain, relatively well-defined number (58-60).
> * This also would not explain why this only occurs in certain
> situations, on certain platforms - that is, the same exact libguac code
> running on EL7 (RHEL, CentOS, etc.) does not result in the resource
> leak, whereas it does on some other set of platforms (Debian, Alpine,
> EulerOS). Unless the pthread library has been changed substantially
> between those versions to not clean up after itself?
>
This *might* now be fixed on master and staging/1.5.5, if folks want to
take a look. The issue does appear to be have been the duplicate
pthread_key_create() calls noted above (pending confirmation with testing).
If this is the cause, it's still unclear why the behavior varies between
platforms. It might be a matter of varying implementations, different
resource limits, or something else platform-specific.
- Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
