Your message dated Tue, 6 Dec 2022 17:52:03 -0500
with message-id
<CAJ0cceY5rAkvb83AWkSoYwSC8NFMVVwJ=qkpvxj4cgfumox...@mail.gmail.com>
and subject line Re: Bug#1024809: podman systemd service running as user
deletes socket file on termination
has caused the Debian Bug report #1024809,
regarding podman systemd service running as user deletes socket file on
termination
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1024809: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024809
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: podman
Version: 3.0.1+dfsg1-3+deb11u1
Severity: normal
Dear Maintainer,
I went to try running podman as a normal user using the systemd service
and socket defined by the Debian package. Namely:
$ systemctl --user start podman.service
The service requires podman.socket which creates:
/run/user/1000/podman/podman.sock
podman-system-service(1) mentions the API listening services expires
after 5 seconds and thus the service self terminate. Which is fine since
a request made to the podman.sock would bring up the service again.
However the service deletes the socket file upon completion and it is
not recreated by podman.socket and the setup is broken.
My workaround has been to make a copy of the service:
cp /lib/systemd/system/podman.service \
~/.config/systemd/user/mypodman.service
Amend it to no more relies on the podman.socket and instruct the service
to stay up indefinitely by passing it --time 0:
ExecStart=/usr/bin/podman $LOGGING system service --time 0
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-0.deb11.2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages podman depends on:
ii conmon 2.0.25+ds1-1.1
ii containerd.io [runc] 1.6.10-1
ii containernetworking-plugins 0.9.0-1+b6
ii crun 0.17+dfsg-1
ii golang-github-containers-common 0.33.4+ds1-1+deb11u1
ii init-system-helpers 1.60
ii iptables 1.8.7-1
ii libc6 2.31-13+deb11u5
ii libdevmapper1.02.1 2:1.02.175-2.1
ii libgpgme11 1.14.0-1+b2
ii libseccomp2 2.5.1-1+deb11u1
Versions of packages podman recommends:
ii buildah 1.19.6+dfsg1-1+b6
ii catatonit 0.1.5-2
ii fuse-overlayfs 1.4.0-1
ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7
ii slirp4netns 1.0.1-2
ii uidmap 1:4.8.1-1
Versions of packages podman suggests:
pn containers-storage <none>
ii docker-compose 1.27.4-3~bpo11+1
-- no debconf information
--- End Message ---
--- Begin Message ---
Thanks for the update.
On Tue, Dec 6, 2022 at 9:22 AM Antoine Musso <[email protected]> wrote:
> Hello Reinhard,
>
> Filing a report upstream was indeed going to be my next step. I
> eventually switched to target the default podman socket (which runs as
> root) since my use case involves the creation of network and Podman 3.0
> does not support that for rootless container.
>
> I had a few other issues such as:
> * the dnsname plugin not being installed at the proper location
> * golang-github-containernetworking-plugin-dnsname not being usable
> under Bullseye:
> ** Does not install dnsmasq-base (#985548, #991525)
> ** The plugin is at /usr/lib/dnsname which prevent it from being
> discovered by podman (fixed by 985549)
>
> And the last one I found is the API service does not have a build cache
> layer https://github.com/containers/podman/issues/12378 (which got
> backported and released in 3.4.3).
>
> Essentially my advanced use case doesn't work with Podman 3.0.1 but it
> works fine with a lot of other things and the CLI is definitely
> pleasant. So at least thank you for the packaging work!
>
> I will try to backport 4.3.1 from testing to Bullseye.
>
Let me know how far you get with that. This is a common request,
but I hesitate because I expect a lot of packages needing to be
required to backport.
>
> Meanwhile, you can close this bug and if I encounter the issue again I
> will file it directly to upstream (thank you for the helpful pointers!).
>
Awesome, thanks!
--
regards,
Reinhard
--- End Message ---
_______________________________________________
Pkg-go-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
