Podman restore container failed
by Ali Hamieh
*HI,*
*When I migrated a podman container from a google cloud rhel 8.3 vm to a
local rhel 8.3 vm, I got the following error when restoring (Checkpoint and
restore podman uses CRIU): *
persmision:1: Error (criu/files-reg.c:2182): File . has bad mode 040755
(expect 040555)
(00.343223) 1: Error (criu/files.c:1357): Can't open root
(00.343659) Error (criu/cr-restore.c:1560): 163252 exited, status=1
(00.343707) Warn (criu/cr-restore.c:2469): Unable to wait 163252: No child
processes
(00.343974) mnt: Switching to new ns to clean ghosts
(00.344242) Error (criu/cr-restore.c:2483): Restoring FAILED.
*And from the local rhel 8.3 vm to the google cloud rhel 8.3 vm, I got:*
bad mode 040555 (expect 040755)
*So bad mode in reverse.*
*Any ideas on how to do a workaround? not necessarily a permanent fix.*
*The container is a podman container: quay.io/adrianreber/counter
<http://quay.io/adrianreber/counter>*
--
Best regards,
Ali Hamieh, PhD
*LinkedIn <https://www.linkedin.com/in/ali-hamieh-phd/>ResearchGate
<https://www.researchgate.net/profile/Ali_Hamieh>*
4 years
Podman Community Cabal Meeting - July 15, 2021 - 10:00 a.m. EDT (UTC-4)
by Tom Sweeney
Hi All,
You may have seen in another discussion started by Erik Bernoth
about having a community meeting that was more of an open forum than
what the Podman Community Meeting is. For the past several months,
Urvashi Mohnani (cc'd) has been running an internal to Red Hat meeting
that we call the "Cabal". People send Urvashi discussion topics, and
they're added to the list. They're generally topics about future
design, interesting issues, or anything related to the containers
projects, Podman, Buildah, and Skopeo. We also generally have an open
forum for a good chunk of time at the end of the meetings.
Given that we are not having a Podman Community Meeting in July, we
decided to make the July Cabal meeting open to the entire community
rather than just the people at Red Hat. If you would like to attend,
please do! If you have a topic that you'd like to be sure that we
discuss, please send a note to Urvashi (cc'd) or myself. Also, send one
of us a note if you'd like to be added to the calendar event. The
meeting is free to attend and will be held via Google meet to start.
The link to the room is: meet.google.com/ieq-pxhy-jbh
In addition, we are planning to hold the Podman Community Cabal
Meeting for the entire community on the third Thursday of the month at
10:00 Eastern from now on. The Cabal meeting will be in addition to the
Podman Community Meeting and not a replacement for it. We still plan to
hold the Podman Community Meetings on the first Tuesday of each month.
I will send a reminder about the Cabal meetings about a week
beforehand to this list, and I will also put something up on the
podman.io site about it too.
Thanks all!
t
4 years
Podman on OpenWrt as user other than root
by W. Michael Petullo
I am trying to modify OpenWrt and its podman package to allow users
other than root to manage containers on that system.
I have made some progress, including working through some "bugs" in
podman and the OpenWrt packages:
https://github.com/containers/podman/issues/9687
https://github.com/containers/storage/pull/851
https://github.com/openwrt/packages/pull/15673
A summary of my work so far exists at
https://github.com/openwrt/packages/issues/15096.
There are two things I do not yet understand, so I am looking for a
summary of how these things work or some recommended reading regarding
them.
(1) Non-root users cannot write to /sys/fs/cgroup/*. I am not sure how to
safely handle this, and I have not yet figured out how other distributions
do it. Does a privileged agent exist that performs the updates to
/sys/fs/cgroup that are necessary to setup a container?
(2) Running "podman run ..." wants to mount /proc and so on in the
container. This fails when run as non-root with "mounting '/proc' to
rootfs at '/proc' caused: operation not permitted." Again, I am not sure
what performs these privileged operations on other distributions.
Thank you,
--
Mike
:wq
4 years
Transitioning from docker: Problems with nftables
by Simon Szustkowski
Hi list,
I am currently experimenting with podman with the ultimate goal to migrate
my small private server from docker to podman. So far so good, but
currently i am struggling with the nftables ruleset which i was managing
the firewall with. This setup was quite good for docker, and i hoped that
all i needed to do is to add the cni-podman0 interface to the list of
container interfaces and am good to go. Unfortunately this is not the case.
This is clearly an issue with nftables and podman's CNI, since i am able to
access any running containers when i completely flush the ruleset. However
i want to post this question here and not in any nftables related
communitys because maybe that's just my misunderstanding of the way how
podman handles networks. To clarify: I am speaking about rootful
containers, since that required me to do the least changes to my ansible
playbooks ;)
So, currently i have a running traefik container, port forwarding to port
80 and 443 on the host, traefik is connected to the default network.
This is an excerpt of my nftables ruleset:
#!/usr/sbin/nft -f
flush ruleset
define podman = cni-podman0
define wan = eth0
table inet firewall {
set tcp_accepted {
type inet_service; flags interval;
elements = {
80,443
}
}
set container_interfaces {
type ifname;
elements = {
docker0,dck-backend,cni-podman0
}
}
chain icoming {
...
#iifname @container_interfaces accept
iifname $podman accept
...
iif $wan tcp dport @tcp_accepted ct state new accept
}
chain forwarding {
type filter hook forward priority 0; policy drop;
# Forward all established and related traffic. Drop invalid traffic.
ct state established,related accept
ct state invalid drop
# Docker
#iifname @container_interfaces ct state new accept
iifname $podman ct state new accept
}
chain outgoing {
type filter hook output priority 0; policy drop;
ct state new,established,related accept
ct state invalid drop
}
}
table ip router {
chain prerouting {
type nat hook prerouting priority 0
}
chain postrouting {
type nat hook postrouting priority 100
oif $wan masquerade persistent
}
}
As you can see i tried to just add the cni-podman0 interface to the set of
container interfaces, since that worked fine when i created additional
docker networks. However this did not allow any incoming traffic to be
routed towards the containers, but traffic originating from the containers
could reach the internet without problems. Afterwards i tried to separate
the podman interface from that set of interfaces because ultimately i hope
to just need one single podman network, but this is also not working.
However, i am able to access the containers from the host itself, a curl
localhst:80 is returning a proper response.
As i said, this ruleset was very fine with docker containers, so maybe
there is something about podman networking internals i am not yet aware of?
Hopefully someone of you could kindly point me to the right direction.
Thank you very much.
4 years
Anyone run Jitsi Meet with Podman on Fedora?
by Philip Rhoades
People,
I am interested in getting Jitsi running and like any first
consideration of this sort of thing, my first thought is using Podman to
do what I want - has anyone had got Jitsi Meet running satisfactorily?
Thanks,
Phil.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
4 years
Podman Community Meeting - Tues June 1, 2021 11:00 a.m. EDT (UTC-4)
by Tom Sweeney
Hi All,
Just a quick note that the next Podman Community Meeting is coming
up a week from this coming Tuesday. It will be Tuesday June 1, 2021 at
11:00 a.m. EDT (UTC-4). We're overloaded with topics this time and
will be talking about Podman and TYE, Podman v3.2.0 updates, Podman in
Kubernetes and Podman Machine updates. The full agenda with the link to
the video conference is here
(https://podman.io/community/meeting/agenda/). Check out the link to
WorldTImeBuddy at the top of the web page for the agenda for an easy
time converter for your local time. As usual, no charge to attend!
Also, I just posted the meeting notes from the May 2021 meeting.
They include links to the slides on Sysbox runtime, a link to the video
recording and my bad attempt at taking notes during the meeting.
https://podman.io/community/meeting/notes/2021-05-04/
As a quick note, given the number of people that we've heard from
who will be on vacation in early July, we have decided to not hold the
meeting that month. Our following meeting will be Tuesday August 3rd,
also at 11:00 a.m. EDT (UTC-4).
t
4 years, 1 month
Container ID 1000 cannot be mapped to a host ID - from pulling an image
by lejeczek
Hi guys.
what is that below
-> $ podman pull ...
...
copying blob caccdbcee96e done
Copying config 482386bf57 done
Writing manifest to image destination
Storing signatures
Error processing tar file(exit status 1): Container ID
1000 cannot be mapped to a host ID
Error: Error committing the finished image: error adding
layer with blob
"sha256:caccdbcee96ed12576a8ccc6350ba68fc2342695b8747fc8dcb60c0c9434d407":
Error processing tar file(exit status 1): Container ID 1000
cannot be mapped to a host ID
would anybody know?
many thanks, L.
4 years, 1 month
logging stopping container
by Hendrik Haddorp
Hi,
I have a test service that does a slow graceful shutdown and logs a few
things while doing so. If I run "podman logs -f <name>" for the
container the logs stop as soon as the container receives the SIGTERM
signal, so once it enters the "stopping" state. Consequently the
terminal containing the "podman run ..." command shows more logs then
the "podman logs -f" command. Shouldn't "podman logs -f" follow the logs
until the container reached the stopped state and the streams got closed
and not only until it starts its shutdown?
regards,
Hendrik
4 years, 1 month
Re: kill container when parent dies
by Hendrik Haddorp
Thanks, I didn't really want to disable the cgroups but I checked the
options again an option is actually `--cgroupns=host`. This way systemd
is able to kill the podman process when the main process of the unit is
being killed. Given that podman had no chance to react the state of the
container is wrong after that and `podman ps` shows the container as
running and an error is logged when stopping the container. So it's an
option but I think it's cleaner to let my unit be restarted on-failure
and then cleanup the state.
On 6/7/21 8:24 PM, Matt Heon wrote:
> You could use `--cgroups=disabled` when starting Podman, which will
> keep it in the same cgroup as the systemd unit and allow systemd to
> kill the container process as well. This does require the use of the
> `crun` OCI runtime (the default everywhere what's not RHEL and CentOS)
> and disable some Podman features, though (most notably resource
> limits, but a few more as well).
>
> Thanks,
> Matt Heon
>
> On Mon, Jun 7, 2021 at 11:57 AM Hendrik Haddorp
> <hendrik.haddorp(a)gmx.net <mailto:hendrik.haddorp@gmx.net>> wrote:
>
> I actually tested about the same. My outer process is running as a
> systemd service and then starts a podman container as part of its
> work.//This also does not make sure that the container gets killed
> when the service gets kill. Systemd kills all process that are
> part of the service (using KillMode=mixed) but it is not able to
> kill all podman processes. I assume it is due to them not being in
> the same cgroup. I can only somewhat resolve it by systemd
> restarting my service on failure and then I can cleanup any still
> running container
>
4 years, 1 month
kill container when parent dies
by Hendrik Haddorp
Hi,
I have a process (A) that starts a podman container as a child process
(B). When A dies due to a crash or gets killed I want the container to
be killed as well. I tried to start B with all kinds of process
attributes, like Setsid = true, Setpgid = true, Pdeathsig = SIGKILL, but
B does not get killed and the container runs on. In fact I see that the
podman process B has another child process and B seems to get reparented
to a "systemd --user" process when A dies.
How can I make sure the podman container dies when the parent process dies?
This is on Linux and rootless.
thanks,
Hendrik
4 years, 1 month
