Some time ago, I had a curious case of very slow DNS resolution in a container on OpenShift. The symptoms were as follows:
- In the PHP application in the container, DNS resolution was very slow with a 5 second delay before the lookup was resolved
- In the container itself, DNS resolution for
curl was very slow, with a 5 second timeout before the lookup was resolved - However, using
dig in the container itself, DNS resolution was instant - Also, on the worker node, the DNS resolution was instant (using both
dig and curl)
TL;DR: Since glibc 2.10, glibc performs IPv4 and IPv6 lookups in parallel. When IPv6 fails, there is a 5 second timeout in many cases before the lookup is returned. Disable IPv6 DNS lookups by setting “single-request” in “resolv.conf” or disable the IPv6 stack completely.
Read the rest of this entry
In the past few months, on all my machines I have replaced Docker with Podman and mostly the transition has been quite smooth. There are still some rough edges here and there, but the overall experience of using Podman has been great!
However, when trying to start a very simple container, one often runs into the following issue:
$ podman run -p80:80 nginx:latest
Error: error from slirp4netns while setting up port redirection: map[desc:bad request: add_hostfwd: slirp_add_hostfwd failed]
The error message looks very cryptic, but the issue is quite simple: As a regular user, one is typically not allowed to bind ports < 1024. So by trying to bind port 80, you will get the error above.
The fix is trivial, just use a port greater than 1024:
$ podman run -p8080:80 -d nginx:latest
22d2be2966e9cb77246a8b698f9024de89f4e6d1a0edfe44209bbe4fd27aa8b5
$ curl localhost:8080
[..]
Welcome to nginx!
[..]
If you really need to use a port number lower than 1024, there are multiple ways to configure that:
- Set
net.ipv4.ip_unprivileged_port_start=80or similar in your sysctl - Add the
CAP_NET_BIND_SERVICE capability to your process or user
Tanuki has released a new version of their wrapper in early October. In this post, I provide version 3.5.41 of the Java Service Wrapper for Windows x64.
As always, I don’t guarantee anything, so please note:
Read the rest of this entry
Tanuki has released a new version of their wrapper on the 4th of July. In this post, I provide version 3.5.40 of the Java Service Wrapper for Windows x64.
As always, I don’t guarantee anything, so please note:
Read the rest of this entry
Shortly after releasing version 3.5.38 of the wrapper, Tanuki has released a new version of their wrapper today. In this post, I provide version 3.5.39 of the Java Service Wrapper for Windows x64.
As always, I don’t guarantee anything, so please note:
Read the rest of this entry
Tanuki has released a new version of their wrapper some days ago. In this post, I provide version 3.5.38 of the Java Service Wrapper for Windows x64.
As always, I don’t guarantee anything, so please note:
Read the rest of this entry
My newest toy is a Garmin Fenix 5 Plus, a very nice smartwatch. In the past, I recorded my steps and other activity data using the Apple Health app on my iPhone. This means that I had a few years worth of activity data that I wanted to move from my Apple Health app to Garmin Connect.
However, that turned out to be not that straight-forward. Garmin only allows you to import GPX, FIT or Fitbit CSV files, not any Apple Health data.
Read the rest of this entry
At their core, containers are just Linux processes that are namespaced. This means in practice, many containers still run as processes on the same host machine. While namespacing processes using cgroups creates very good boundaries between processes, the isolation is still not perfect.
Read the rest of this entry
A user of the Tanuki Service Wrapper reminded me that Tanuki released version 3.5.37 of the Java Service Wrapper some time ago. So in this post, I can provide version 3.5.37 of the Java Service Wrapper for Windows x64.
As always, I don’t guarantee anything, so please note:
Read the rest of this entry