Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker REST API: logs: until=0 does not return any log #10859

Closed
gdesmott opened this issue Jul 5, 2021 · 2 comments · Fixed by #10868
Closed

docker REST API: logs: until=0 does not return any log #10859

gdesmott opened this issue Jul 5, 2021 · 2 comments · Fixed by #10868
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@gdesmott
Copy link

gdesmott commented Jul 5, 2021

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When fetching logs using Docker REST API with until=0 (the default), podman does not return any log while Docker returns them all.
I suppose Docker parses 0 as "no end" while podman uses it strictly.

Steps to reproduce the issue:

$ curl --unix-socket /var/run/user/$UID/podman/podman.sock -v \
  --output - \
  --header "Content-Type: application/json" \
  --header "Accept:" \
  --header "User-Agent:" \
  http://localhost/containers/$CONTAINER/logs?follow=true\&stdout=true\&until=0

Describe the results you received:

*   Trying /var/run/user/1000/podman/podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> GET /containers/test-container/logs?follow=true&stdout=true&until=0 HTTP/1.1
> Host: localhost
> Content-Type: application/json
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Api-Version: 1.40
< Libpod-Api-Version: 3.2.1
< Server: Libpod/3.2.1 (linux)
< Date: Mon, 05 Jul 2021 10:08:33 GMT
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

Describe the results you expected:

Here is the result when running the same request on docker:

* Connected to localhost (/run/docker.sock) port 80 (#0)
> GET /containers/fc250e2baf6b/logs?follow=true\&stdout=true\&until=0 HTTP/1.1
> Host: localhost
> Content-Type: application/json
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Api-Version: 1.41
< Docker-Experimental: true
< Ostype: linux
< Server: Docker/20.10.5+dfsg1 (linux)
< Date: Mon, 05 Jul 2021 10:00:23 GMT
< Transfer-Encoding: chunked
< 
a/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
J/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
V/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
^10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
`10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
R/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
R/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
B/docker-entrypoint.sh: Configuration complete; ready for start up

Output of podman version:

podman version 3.2.1

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.21.0
  cgroupControllers: []
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.27-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 8
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: cass-t14
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.12.13-300.fc34.x86_64
  linkmode: dynamic
  memFree: 1743785984
  memTotal: 33274310656
  ociRuntime:
    name: crun
    package: crun-0.20.1-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 25279586304
  swapTotal: 25295839232
  uptime: 118h 48m 41.44s (Approximately 4.92 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/cassidy/.config/containers/storage.conf
  containerStore:
    number: 67
    paused: 0
    running: 5
    stopped: 62
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.5.0-1.fc34.x86_64
      Version: |-
        fusermount3 version: 3.10.4
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.4
        using FUSE kernel interface version 7.31
  graphRoot: /var/home/cassidy/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 107
  runRoot: /run/user/1000/containers
  volumePath: /var/home/cassidy/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.1
  Built: 1623697949
  BuiltTime: Mon Jun 14 21:12:29 2021
  GitCommit: ""
  GoVersion: go1.16.3
  OsArch: linux/amd64
  Version: 3.2.1

Package info (e.g. output of rpm -q podman or apt list podman):

 podman-3:3.2.1-1.fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

No

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Jul 5, 2021
@gdesmott
Copy link
Author

gdesmott commented Jul 5, 2021

Actually setting until with whatever value seems to always return an empty result.

gdesmott pushed a commit to gdesmott/bollard that referenced this issue Jul 5, 2021
When requesting logs, Bollard sets all the REST parameters to their default values.
This works fine with Docker but not with Podman which does not return
any log if 'until' is set: containers/podman#10859

Workaround it by wrapping all the parameters with None so they are
omitted from the REST request if not defined.
gdesmott pushed a commit to gdesmott/bollard that referenced this issue Jul 5, 2021
When requesting logs, Bollard sets all the REST parameters to their default values.
This works fine with Docker but not with Podman which does not return
any log if 'until' is set: containers/podman#10859

Workaround it by skipping the 'until' argument if 0.
@cdoern cdoern self-assigned this Jul 6, 2021
@cdoern
Copy link
Contributor

cdoern commented Jul 6, 2021

Looking into this, seems like until has some fixes that need to be added. Right now we parse until as a since but that doesn't seem to be accurate @gdesmott

cdoern added a commit to cdoern/podman that referenced this issue Jul 9, 2021
compat containers/logs was missing actual usage of until query param.

fixes containers#10859

Signed-off-by: cdoern <cdoern@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 21, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants