[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DLA 773-1 and DLA 773-2

On Mon, Jan 09, 2017 at 07:52:58PM +0000, Chris Lamb wrote:
> Guido Günther wrote:
> > I had the same problem with flake8 in gbp and used
> > 
> >     flake8 -j1
> > 
> > to work around this. I think we can only skip the patch if hitting a
> > EPERM.
> I'm a little confused by the mention of flake8 here - the test itself
> is requiring access to the multiprocessing library (+ /dev/shm etc.)
> rather than calling flake8 and that failing AFAICT

Flake8 does the same internally what the test does (using the
multiprocess module):

Traceback (most recent call last):
  File "/usr/bin/flake8", line 11, in <module>
    load_entry_point('flake8==3.2.1', 'console_scripts', 'flake8')()
  File "/usr/lib/python3/dist-packages/flake8/main/cli.py", line 16, in main
  File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 322, in run
  File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 305, in _run
  File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 301, in initialize
  File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 227, in make_file_checker_manager
  File "/usr/lib/python3/dist-packages/flake8/checker.py", line 94, in __init__
    self.process_queue = multiprocessing.Queue()
  File "/usr/lib/python3.5/multiprocessing/context.py", line 101, in Queue
    return Queue(maxsize, ctx=self.get_context())
  File "/usr/lib/python3.5/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/usr/lib/python3.5/multiprocessing/context.py", line 66, in Lock
    return Lock(ctx=self.get_context())
  File "/usr/lib/python3.5/multiprocessing/synchronize.py", line 163, in __init__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/usr/lib/python3.5/multiprocessing/synchronize.py", line 60, in __init__
PermissionError: [Errno 13] Permission denied

This is because in the chroot

    $ ls -ld /dev/shm/
    drwxr-xr-x 2 root root 40 Dec 18 22:42 /dev/shm/

whereas outside the chroot

    $ ls -ld /dev/shm/
    drwxrwxrwt 2 root root 280 Jan  9 20:51 /dev/shm/

After a

    chmod 1777 /dev/shm/

inside the chroots this passes. I always thought restricting permissions
on /dev/shm in the chroot was intentional but maybe it's just a bug?

> I could, however skip the test on EPERM, but this issue seems like
> more of a buildd admin issue… ?

It's at least consistent in pbuilder chroots as well.

 -- Guido

Reply to: