[Lxc-users] procfs and unnamed pipes

[Serge Hallyn]

Quoting Timofey.Kirillov (distorhead at gmail.com):
> 06.02.2013 21:48, Serge Hallyn пишет:
> >Quoting Timofey.Kirillov (distorhead at gmail.com):
> >>Hi,
> >>
> >>I have a question about using unnamed pipes with procfs.
> >>
> >>Suppose a chrooted environment with proc mounted as procfs. I am
> >>trying to use bash process substitution feature and get this:
> >>
> >>$ cat <(echo hello)
> >>cat: /dev/fd/63: No such file or directory
> >works fine for me in a chroot.
> >
> >My first guess would be that your chroot doesn't have the /dev/fd ->
> >/proc/self/fd symlink set up right, though your discussion below
> >suggests that's not the case.
> >
> >>While on the normal system:
> >>$ cat <(echo hello)
> >>hello
> >>
> >>As I understand, the problem is that when fuse making getattr on
> >Sorry I don't know where fuse comes in.
> >
> >>file '/dev/fd/63' - it determines that it is symlink. The next step
> >>is readlink, which gives something like that: /25977/fd/63 =>
> >>pipe:[3087676]. And at the final step getattr on file
> >>'/25977/fd/pipe:[3087676]' gives no such file or directory.
> >>
> >>Actually I encouter this issue while working on similar fuse proc
> >>(for jail environments). Then I find procfs, tried it out and get
> >>the same failure.
> >>
> >>I've also tried to change logic of getattr in the next way. First
> >>make normal stat of file. If it is not S_ISFIFO - make lstat. In
> >>that way the process hangs forever on open syscall:
> >>$ strace cat <(echo hello)
> >>...
> >>open("/dev/fd/63", O_RDONLY
> >>
> >>
> >>Is there any workaround for this problem?
> >I can't reproduce your problem.  Which kernel are you on?
> >
> >-serge
> 
> Thanks for the answer.
> 
> I am trying to use this fuse procfs:
> http://lxc.sourceforge.net/download/procfs/

Yes, but you said

>(for jail environments). Then I find procfs, tried it out and get
>the same failure.

If you get the same failure when just using procfs in the chroot,
then something funky is going on.  If it's with the fusefs only,
then it seems safe to assume it's a bug in the fusefs :)

-serge