Support guidelines
I've found a bug and checked that ...
Description
{{ .Meta.Hostname }} does not show a plain text hostname as i would have expected, but a hex-digit string. Regardless of hostname length these hex-digit strings are always of the same length. Maybe .Meta.Hostname resolves to a memory address and not to the content where this address points to.
Expected behaviour
.Meta.Hostname should resolve to a plain text hostname
Actual behaviour
.Meta.Hostname resolves to hex-digit srting
Steps to reproduce
Use it in Message Body or in Message Title
Diun version
4.33.0
Docker info
raspi-02 ~ # docker info
Client:
Version: 29.1.3
Context: default
Debug Mode: false
Plugins:
compose: Docker Compose (Docker Inc.)
Version: v5.0.1
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 6
Running: 6
Paused: 0
Stopped: 0
Images: 6
Server Version: 29.1.3
Storage Driver: overlay2
Backing Filesystem: btrfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 301b2dac98f15c27117da5c8af12118a041a31d9
runc version: c241c0bb5e60a8e8c1b2e53d4eca8d0068d8d57e
init version: de40ad007797e0dcd8b7126f27bb87401d224240
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.18.36-v8-4k+
Operating System: Gentoo Linux
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 7.76GiB
Name: raspi-02.trenker.xyz
ID: 84e844af-b0fb-474b-97a9-6812b2593115
Docker Root Dir: /var/data01/docker
Debug Mode: false
Username: strenker
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables
Docker Compose config
name: diun
services:
diun:
image: crazymax/diun:latest
command: serve
restart: always
volumes:
- "/var/data01/diun/volumes/data:/data"
- "/var/run/docker.sock:/var/run/docker.sock"
environment:
- "TZ=Europe/Berlin"
- "DIUN_WATCH_WORKERS=10"
- "DIUN_WATCH_SCHEDULE=0 */6 * * *"
- "DIUN_WATCH_JITTER=30s"
- "DIUN_PROVIDERS_DOCKER=true"
- "DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true"
- "DIUN_WATCH_FIRSTCHECKNOTIF=true"
- "DIUN_NOTIF_MAIL_HOST=mailhost"
- "DIUN_NOTIF_MAIL_PORT=587"
- "DIUN_NOTIF_MAIL_INSECURESKIPVERIFY=false"
- "DIUN_NOTIF_MAIL_USERNAME=user"
- "DIUN_NOTIF_MAIL_PASSWORD=secret"
- "DIUN_NOTIF_MAIL_FROM=user"
- "DIUN_NOTIF_MAIL_TO=user1,user2"
healthcheck:
test: ["CMD", "diun", "healthcheck"]
interval: 30s
timeout: 5s
retries: 3
start_period: 60s
labels:
- "diun.enable=true"Logs
Thu, 25 Jun 2026 10:59:48 CEST INF Starting Diun version=v4.33.0
Thu, 25 Jun 2026 10:59:48 CEST INF Configuration loaded from 14 environment variable(s)
Thu, 25 Jun 2026 10:59:48 CEST INF Cron triggered
Thu, 25 Jun 2026 10:59:48 CEST INF gRPC server listening addr=[::]:42286
Thu, 25 Jun 2026 10:59:48 CEST INF Found 6 image(s) to analyze provider=docker
Thu, 25 Jun 2026 10:59:49 CEST INF Jobs completed added=0 failed=0 skipped=0 unchanged=6 updated=0
Thu, 25 Jun 2026 10:59:49 CEST INF Cron initialized with schedule 0 */6 * * *
Thu, 25 Jun 2026 10:59:49 CEST INF Next run in 1 hour (2026-06-25 12:00:29.482140996 +0200 CEST)
Additional info
No response
Support guidelines
I've found a bug and checked that ...
Description
{{ .Meta.Hostname }} does not show a plain text hostname as i would have expected, but a hex-digit string. Regardless of hostname length these hex-digit strings are always of the same length. Maybe .Meta.Hostname resolves to a memory address and not to the content where this address points to.
Expected behaviour
.Meta.Hostname should resolve to a plain text hostname
Actual behaviour
.Meta.Hostname resolves to hex-digit srting
Steps to reproduce
Use it in Message Body or in Message Title
Diun version
4.33.0
Docker info
Docker Compose config
Logs
Additional info
No response