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]
