Hi guys I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to: -> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug) does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble. How to troubleshoot issues like this? many thanks, L.
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately. --security-opt label=disable --security-opt seccomp=unconfined --cap-add all Which would tell you that SELinux is blocking it, Seccomp, or capabilities. If it is capabilities, then we can start playing with which capability is needed.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON` By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately. many thanks, L.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 4/30/21 06:47, lejeczek via Podman wrote:
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON`
By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately.
many thanks, L.
Please update to the lastes libcap version. This basically means that the tools are using CAP_PERFMON which is not translated to the correct constants by the library, because the library is out of date.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 4/30/21 06:47, lejeczek via Podman wrote:
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote:
Hi guys
I'm trying a popular image, perhaps very popular(not sure if with podman consumers though) off which a rootful container produces no logs. I've tried podman vers 2.0 & 3.1, with the same results. Adding debug to:
-> $ podman container restart cni-net.disc --log-level=debug ... INFO[0000] Running conmon under slice machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice and unitName libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope
DEBU[0000] Received: 310116 INFO[0000] Got Conmon PID as 310113 DEBU[0000] Created container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 in OCI runtime DEBU[0000] Starting container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 with command [/bin/bash] DEBU[0000] Started container 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97
DEBU[0000] Called restart.PersistentPostRunE(podman container restart cni-net.discourse --log-level=debug)
does not reveal much as you can see. I can: -> $ podman exec -it cni-net.disc sh and shell is availble.
How to troubleshoot issues like this? many thanks, L. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON`
By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately.
many thanks, L.
Please update to the lastes libcap version. This basically means that the tools are using CAP_PERFMON which is not translated to the correct constants by the library, because the library is out of date. Which version of the lib should have it fixed? I have
On 03/05/2021 20:27, Daniel Walsh wrote: libcap-2.26-4.el8.x86_64. (which I think it the high/latest available in CentOS Stream)
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 5/4/21 10:09, lejeczek via Podman wrote:
On 4/30/21 06:47, lejeczek via Podman wrote:
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote:
On 4/28/21 11:02, lejeczek via Podman wrote: > Hi guys > > I'm trying a popular image, perhaps very popular(not sure if > with podman consumers though) off which a rootful container > produces no logs. > I've tried podman vers 2.0 & 3.1, with the same results. > Adding debug to: > > -> $ podman container restart cni-net.disc --log-level=debug > ... > INFO[0000] Running conmon under slice > machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice > and unitName > libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope > > DEBU[0000] Received: 310116 > INFO[0000] Got Conmon PID as 310113 > DEBU[0000] Created container > 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 > in OCI runtime > DEBU[0000] Starting container > 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 > with command [/bin/bash] > DEBU[0000] Started container > 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 > 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 > DEBU[0000] Called restart.PersistentPostRunE(podman container > restart cni-net.discourse --log-level=debug) > > does not reveal much as you can see. > I can: > -> $ podman exec -it cni-net.disc sh > and shell is availble. > > How to troubleshoot issues like this? > many thanks, L. > _______________________________________________ > Podman mailing list -- podman@lists.podman.io > To unsubscribe send an email to podman-leave@lists.podman.io
I would first attempt it --privileged and see if it works. If it does, then we got to find out what security mechanism is blocking it.
'--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON`
By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately.
many thanks, L.
Please update to the lastes libcap version. This basically means that the tools are using CAP_PERFMON which is not translated to the correct constants by the library, because the library is out of date. Which version of the lib should have it fixed? I have
On 03/05/2021 20:27, Daniel Walsh wrote: libcap-2.26-4.el8.x86_64. (which I think it the high/latest available in CentOS Stream)
We are using 2.48 on Fedora. Where did you get the Podman from?
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On 04/05/2021 20:23, Daniel Walsh wrote:
On 5/4/21 10:09, lejeczek via Podman wrote:
On 4/30/21 06:47, lejeczek via Podman wrote:
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote:
On 28/04/2021 19:56, Daniel Walsh wrote: > On 4/28/21 11:02, lejeczek via Podman wrote: >> Hi guys >> >> I'm trying a popular image, perhaps very >> popular(not sure if with podman consumers though) >> off which a rootful container produces no logs. >> I've tried podman vers 2.0 & 3.1, with the same >> results. >> Adding debug to: >> >> -> $ podman container restart cni-net.disc >> --log-level=debug >> ... >> INFO[0000] Running conmon under slice >> machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice >> and unitName >> libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope >> >> DEBU[0000] Received: 310116 >> INFO[0000] Got Conmon PID as 310113 >> DEBU[0000] Created container >> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >> in OCI runtime >> DEBU[0000] Starting container >> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >> with command [/bin/bash] >> DEBU[0000] Started container >> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >> >> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >> >> DEBU[0000] Called restart.PersistentPostRunE(podman >> container restart cni-net.discourse --log-level=debug) >> >> does not reveal much as you can see. >> I can: >> -> $ podman exec -it cni-net.disc sh >> and shell is availble. >> >> How to troubleshoot issues like this? >> many thanks, L. >> _______________________________________________ >> Podman mailing list -- podman@lists.podman.io >> To unsubscribe send an email to >> podman-leave@lists.podman.io > > I would first attempt it --privileged and see if it > works. If it does, then we got to find out what > security mechanism is blocking it. > '--privileged' gets me back to what I inquired about and filed bugzilla earlier - CAP_PERFMON I wonder, is a 'proper' fix moving to appear on the horizon?
If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON`
By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately.
many thanks, L.
Please update to the lastes libcap version. This basically means that the tools are using CAP_PERFMON which is not translated to the correct constants by the library, because the library is out of date. Which version of the lib should have it fixed? I have
On 03/05/2021 20:27, Daniel Walsh wrote: libcap-2.26-4.el8.x86_64. (which I think it the high/latest available in CentOS Stream)
We are using 2.48 on Fedora.
Where did you get the Podman from? I'm on CentOS Stream, so it's all Centos. Seems that the default module - container-tools:rhel8 lags behind 3.0 module, although podman itself is in higher version. I've now reverted to lower ver of podman but higher version of other bits, all from container-tools:3.0 Meanwhile I've tired 2.48-2.el8, rebuilt on CentOS but still no luck, with it I get: ... ERRO[0000] error starting some container dependencies ERRO[0000] "unknown cap: `CAP_CHECKPOINT_RESTORE`: OCI runtime error" Error: error starting some containers: internal libpod error
podman-3.0.1-6.module_el8.5.0+736+58cc1a5a.x86_64 criu-3.15-1.module_el8.5.0+736+58cc1a5a.x86_64 libcap-2.48-2.el8.x86_64
> _______________________________________________ > Podman mailing list -- podman@lists.podman.io > To unsubscribe send an email to > podman-leave@lists.podman.io _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
This looks like we need newer versions of runc and crun to be able to handle the missing CAP_PERFMON, Hopefully this library gets updated as well. On 5/4/21 16:09, lejeczek via Podman wrote:
On 04/05/2021 20:23, Daniel Walsh wrote:
On 5/4/21 10:09, lejeczek via Podman wrote:
On 4/30/21 06:47, lejeczek via Podman wrote:
On 29/04/2021 20:47, Daniel Walsh wrote:
On 4/28/21 16:46, lejeczek via Podman wrote: > > > On 28/04/2021 19:56, Daniel Walsh wrote: >> On 4/28/21 11:02, lejeczek via Podman wrote: >>> Hi guys >>> >>> I'm trying a popular image, perhaps very popular(not sure if >>> with podman consumers though) off which a rootful container >>> produces no logs. >>> I've tried podman vers 2.0 & 3.1, with the same results. >>> Adding debug to: >>> >>> -> $ podman container restart cni-net.disc --log-level=debug >>> ... >>> INFO[0000] Running conmon under slice >>> machine-libpod_pod_6ef5202d6954f3616a530f188954465e27ff4730dfad32b68d9467c26e789d18.slice >>> and unitName >>> libpod-conmon-7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97.scope >>> >>> DEBU[0000] Received: 310116 >>> INFO[0000] Got Conmon PID as 310113 >>> DEBU[0000] Created container >>> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >>> in OCI runtime >>> DEBU[0000] Starting container >>> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >>> with command [/bin/bash] >>> DEBU[0000] Started container >>> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >>> 7b001c9305379c7279791e9addf01a716188b42c2c7d52b54deea0ca7461be97 >>> DEBU[0000] Called restart.PersistentPostRunE(podman container >>> restart cni-net.discourse --log-level=debug) >>> >>> does not reveal much as you can see. >>> I can: >>> -> $ podman exec -it cni-net.disc sh >>> and shell is availble. >>> >>> How to troubleshoot issues like this? >>> many thanks, L. >>> _______________________________________________ >>> Podman mailing list -- podman@lists.podman.io >>> To unsubscribe send an email to podman-leave@lists.podman.io >> >> I would first attempt it --privileged and see if it works. If >> it does, then we got to find out what security mechanism is >> blocking it. >> > '--privileged' gets me back to what I inquired about and filed > bugzilla earlier - CAP_PERFMON > I wonder, is a 'proper' fix moving to appear on the horizon? > If --privileged works, now I would try each of the following separately.
--security-opt label=disable
--security-opt seccomp=unconfined
--cap-add all
Which would tell you that SELinux is blocking it, Seccomp, or capabilities.
If it is capabilities, then we can start playing with which capability is needed. Sorry, I did not make it straight enough, it fails with:
-> $ _P=cni-net _N=disco-dev; podman run --privileged -td --pod=$_P.${HOSTNAME%%.*} --volume /srv/containers/FLATfiles/net.disco:/shared:z --name ${_P}.$_N docker.io/discourse/discourse_dev Error: OCI runtime error: unknown cap: `CAP_PERFMON`
By 'fails' I mean - container gets created by still no logs. Only config where 'logs -f' actually connects and hangs onto something is: -> $ podman run --security-opt label=disable --restart=always -td --pod=.... But still that something is 'blank' output, otherwise '-f' returns to prompt immediately.
many thanks, L.
Please update to the lastes libcap version. This basically means that the tools are using CAP_PERFMON which is not translated to the correct constants by the library, because the library is out of date. Which version of the lib should have it fixed? I have
On 03/05/2021 20:27, Daniel Walsh wrote: libcap-2.26-4.el8.x86_64. (which I think it the high/latest available in CentOS Stream)
We are using 2.48 on Fedora.
Where did you get the Podman from? I'm on CentOS Stream, so it's all Centos. Seems that the default module - container-tools:rhel8 lags behind 3.0 module, although podman itself is in higher version. I've now reverted to lower ver of podman but higher version of other bits, all from container-tools:3.0 Meanwhile I've tired 2.48-2.el8, rebuilt on CentOS but still no luck, with it I get: ... ERRO[0000] error starting some container dependencies ERRO[0000] "unknown cap: `CAP_CHECKPOINT_RESTORE`: OCI runtime error" Error: error starting some containers: internal libpod error
podman-3.0.1-6.module_el8.5.0+736+58cc1a5a.x86_64 criu-3.15-1.module_el8.5.0+736+58cc1a5a.x86_64 libcap-2.48-2.el8.x86_64
>> _______________________________________________ >> Podman mailing list -- podman@lists.podman.io >> To unsubscribe send an email to podman-leave@lists.podman.io > _______________________________________________ > Podman mailing list -- podman@lists.podman.io > To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
participants (2)
-
Daniel Walsh -
lejeczek