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.
CheersAntoine
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 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.4On 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]
---------------------------------------------------------------------To
unsubscribe, e-mail: [email protected] additional
commands, e-mail: [email protected]
