Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Mar 2016 12:40:19 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 207838] [zfs] getcwd fails with permission denied under load
Message-ID:  <bug-207838-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207838

            Bug ID: 207838
           Summary: [zfs] getcwd fails with permission denied under load
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: h2+fbsdports@fsfe.org

I have a machine running a large number of nightly builds and unit tests ev=
ery
night, maybe more than 8000 targets/tests in all compiler/flag combinations.
Every once in a while (on average maybe one per night) a random one of the
builds fails with:
gmake: getcwd: Permission denied

Also sometimes the build of the manual (a python process), fails with:
os.path.join(os.getcwd(), 'dummy'),
OSError: [Errno 13] Permission denied


The system:
FreeBSD <snip> 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12
15:26:37 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GEN=
ERIC
 amd64

The system is running a ZFS mirror on two SSDs and the relevant datasets ar=
e:
zssdroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zssdroot/nightly-builds on /usr/home/mi/h4nn3s/nightly-builds (zfs, local,
noatime, nfsv4acls)
-> the /tmp is not a tmpfs


The situation is a little annoying, because it permanently produces false
positives in the build matrix...

Anything I can do to help diagnose / fix this?

Thank you for your help!

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207838-8>