github-actions[bot]
commented
1 month ago Pinging code owners:
-
receiver/podman: @rogercoll
See Adding Labels via Comments if you do not have permissions to add labels yourself.
Open cforce opened 1 month ago
github-actions[bot]
commented
1 month ago Pinging code owners:
receiver/podman: @rogercoll
See Adding Labels via Comments if you do not have permissions to add labels yourself.
rogercoll
commented
1 month ago Thanks for raising this.
The connection strategy was mostly copy/paste from https://github.com/containers/podman/blob/main/pkg/bindings/connection.go#L90. And you are correct, the implementation is adding an extra "/" for non-absolute paths unix sockets. I reckon that both forms should work in most situations, but relying on unix:/// is safer when specifying absolute paths to avoid any possible misinterpretation by the system or application.
Does your socket exist in /run/podman/podman.sock?
cforce
commented
1 month ago Yes, looks all good for me - I have added below debug logs in same shell where otelcol is executed later
echo "podman info:"
podman info
echo "Debugging info"
echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR"
ls -al $XDG_RUNTIME_DIR/*.sock || true
echo "/run/user/podman/"
ls -al /run/user/podman/*.sock || true
and output
podman info:
host:
arch: amd64
buildahVersion: 1.28.2
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- rdma
cgroupManager: cgroupfs
cgroupVersion: v2
conmon:
package: conmon_2.1.6+ds1-1_amd64
path: /usr/bin/conmon
version: 'conmon version 2.1.6, commit: unknown'
cpuUtilization:
idlePercent: 62.46
systemPercent: 14.2
userPercent: 23.34
cpus: 2
distribution:
codename: bookworm
distribution: debian
version: "12"
eventLogger: file
hostname: runner-jlguopmm-project-45956638-concurrent-0
idMappings:
gidmap: null
uidmap: null
kernel: 5.15.154+
linkmode: dynamic
logDriver: k8s-file
memFree: 5200777216
memTotal: 8341037056
networkBackend: cni
ociRuntime:
name: crun
package: crun_1.8.1-1+deb12u1_amd64
path: /usr/bin/crun
version: |-
crun version 1.8.1
commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
rundir: /run/user/podman/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: unix:///run/user/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: true
slirp4netns:
executable: ""
package: ""
version: ""
swapFree: 2147479552
swapTotal: 2147479552
uptime: 0h 2m 0.00s
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries: {}
store:
configFile: /usr/share/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/lib/containers/storage
graphRootAllocated: 272[265](https://gitlab.com/Mercedes-Intelligent-Cloud/mic-monlog/micotelcollector/-/jobs/7538892225#L265)42080
graphRootUsed: 9394491392
graphStatus:
Backing Filesystem: overlayfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /builds/Mercedes-Intelligent-Cloud/mic-monlog/micotelcollector
imageStore:
number: 0
runRoot: /run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.3.1
Built: 0
BuiltTime: Thu Jan 1 00:00:00 1970
GitCommit: ""
GoVersion: go1.19.8
Os: linux
OsArch: linux/amd64
Version: 4.3.1
Debugging info
XDG_RUNTIME_DIR=/run/user/podman
srw------- 1 root root 0 Aug 8 17:11 /run/user/podman/podman.sock
/run/user/podman/
srw------- 1 root root 0 Aug 8 17:11 /run/user/podman/podman.sock
/run/user/root/Ok --Path was wrong.
rogercoll
commented
1 month ago Ok --Path was wrong.
Great we found out the root problem, do you think we can close the issue?
cforce
commented
1 month ago I still think the message and the wrong path composed because of some strange fallback default is completely misleading and shall be improved
rogercoll
commented
1 month ago Although the receiver is just propagating the error retrieved from the libpod package, I agree that the error message could be improved. Regarding the path fallback strategy, I would prefer to rely on what the containers/podman package does.
@cforce Would you be interested in opening a PR to improve the error message?
Component(s)
receiver/podman
What happened?
Description
The endpoint used differs from the one configured. An exrta "/" is injected for unknown reasons
"dial unix /run//podman/podman.sock: "
but configured is
"endpoint: unix://run/podman/podman.sock"
Maybe docs are buggy and we ned to use escape for ":" or /"?
see https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/podmanreceiver
Collector version
0.106.1
Environment information
Environment
OpenTelemetry Collector configuration
Log output
Additional context
No response