Closed onlyjob closed 1 year ago
Can you provide additional details on how you're launching Podman - an exact command line to reproduce would be greatly helpful.
Something like podman build --no-cache --rm --force-rm -t centos7-app .
Build script invokes expect
script that fails... It is a straightforward script:
#!/usr/bin/expect
set timeout 99
stty columns 80 rows 25
spawn bash /var/tmp/appsetup-linux.sh
sleep .5
expect "Please enter the fully qualified name, including domain information, of this host machine*" {
send "localhost\n"
}
interact
It is invoked as runuser -u appuser /var/tmp/appsetup-linux.expect
during container build.
@TomSweeneyRedHat PTAL
@onlyjob Could you try this against buildah in both rootful and rootless mode. Also have you tried this against the podman 3.0 rc?
In podman 3.0.0~rc2 (mentioned in title) it appears to work under root. I'll check if buildah is affected and report...
Reproduced the problem in Podman_3.0.0 and Buildah_1.19.4, both rootless.
If you run that command in your user session, non root, do you run out of the ptys as well?
If you run that command in your user session, non root, do you run out of the ptys as well?
Apparently not... expect
don't complain under podman run -it
(rootless)...
Are you saying it only runs out if you don't use -i?
It runs fine with run -it
but fails during build -t
stage.
On root it runs fine in either mode. @giuseppe Thoughts?
Basically -i keeps stdin open. But it might do something with the tty.
You could so try this with crun and runc, to see if they react any differently.
A friendly reminder that this issue had no activity for 30 days.
@onlyjob I never heard back on the previous question. Please respond.
A friendly reminder that this issue had no activity for 30 days.
You could so try this with crun and runc, to see if they react any differently.
I did not have a chance to try that. The problem manifested with crun
. Did you have a chance to reproduce?
Have not been able to reproduce, please try it against current code, and /or generate a reproducer we can test against.
A friendly reminder that this issue had no activity for 30 days.
Just tried again on 3.0.1, still the same problem. :(
Can you contribute a Containerfile that shows the failure?
A friendly reminder that this issue had no activity for 30 days.
Since we have had no feedback in a month, I am going to close. Reopen if you have the feedback.
I can only comment but not reopen... I'm sorry that I could not provide a perfect reproducer (no time!) but this bug report is complete with everything that is needed for replicating the issue.
Minimal reproducer:
FROM debian:unstable
RUN apt-get update \
&& apt-get install -y --no-install-recommends \
expect \
&& rm -rf /var/lib/apt/lists/*
RUN expect -c 'spawn echo 1'
Build with:
podman build --network host -f test9_dockerfile someemptydir
Expected result:
Does not print:
STEP 3/3: RUN expect -c 'spawn echo 1'
spawn echo 1
The system has no more ptys. Ask your system administrator to create more.
while executing
"spawn echo 1"
relevant strace excerpt from a similiar but different setup:
write(1, "spawn", 5spawn) = 5
write(1, " ", 1 ) = 1
write(1, "1", 11) = 1
write(1, "\r\r\n", 3
) = 3
openat(AT_FDCWD, "/dev/ptmx", O_RDWR) = 4
ioctl(4, TIOCGPTN, 0x7ffcfee9a1f4) = -1 EACCES (Permission denied)
close(4) = 0
close(-1) = -1 EBADF (Bad file descriptor)
close(-1) = -1 EBADF (Bad file descriptor)
openat(AT_FDCWD, "/", O_RDONLY) = 4
close(4) = 0
write(2, "The system has no more ptys. As"..., 105The system has no more ptys. Ask your system administrator to create more.
while executing
"spawn 1") = 105
This might very well be a bug in expect
, https://sources.debian.org/src/expect/5.45.4-2/exp_command.c/?hl=873#L873 is where the error message is printed.
It seems that the code responsible is here https://sources.debian.org/src/expect/5.45.4-2/pty_termios.c/#L390
And a (horrible) C code reproducer:
#include <assert.h>
#include <stdio.h>
#include <fcntl.h>
#define __USE_XOPEN_EXTENDED 1
#include <stdlib.h>
int main(int argc, char *argv[]) {
int master = open("/dev/ptmx", O_RDWR);
if (master == -1) {
return EXIT_FAILURE;
}
char * v = ptsname(master);
printf("ptsname => '%s'\n", v);
return EXIT_SUCCESS;
}
in podman:
openat(AT_FDCWD, "/dev/ptmx", O_RDWR) = 3
ioctl(3, TIOCGPTN, 0x7ffc88b3bdfc) = -1 EACCES (Permission denied)
outside:
openat(AT_FDCWD, "/dev/ptmx", O_RDWR) = 3
ioctl(3, TIOCGPTN, [44]) = 0
Please disregard the above, I managed to block the TIOCGPTN ioctl and didn't double check.
For some reason I was expecting SELinux to block with EPERM not EACCES, and I didn't double check first.
Sorry for the noise.
A friendly reminder that this issue had no activity for 30 days.
Sadly in a couple of years no one has picked this up.
That's a shame. I've hit this issue trying to build an Oracle database container using Podman.
Does it work with rootful podman?
Does it work with rootful podman?
For me it does yes.
My guess would be rootless users have a limited number of ptys or open files that you are hitting. Perhaps something in ulimit.
$ ulimit -a
real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 256064
max locked memory (kbytes, -l) 8192
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 256064
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
These limits are the same
$ cat /proc/sys/kernel/pty/max 4096 $ sudo cat /proc/sys/kernel/pty/max 4096
But maybe root is able to ignore these since it has cap_sys_resource
A friendly reminder that this issue had no activity for 30 days.
Since I have not heard back, I am going to close. Continue the conversation here.
Since few releases ago (going several weeks back) I can't (re-)build a particular container image any more due to
expect
binary failing (inspawn
command) as follows in rootless mode:(Formerly this container image was building fine by the older release of Podman).
expect(1) man page mentions the following:
I'm not sure whether this have something to do with kernel,
runc
,crun
or other system components. I've tried withrunc
andcrun
but reproduced the problem with both of them. Podman 2.0.6 on Debian "testing"/"unstable" had no such problem.Here is the current output of
podman info
:CC: @siretart.