|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 19, 2007, at 3:55 AM, Jan Danielsson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
David Holland wrote:
On Wed, Sep 19, 2007 at 02:39:02AM +0200, Jan Danielsson wrote:
http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=36963
[...]
Are you running a multiprocessor kernel?
No; just a single processor. Unfortunately.
(And if you haven't yet, try turning on DIAGNOSTIC and LOCKDEBUG.)
I haven't done that; I'll be sure to do that on next rebuild.
I would just like to check if anyone has any interest in this
problem.
Definitely - the more information you can collect, the better.
Good; I just wanted to know that I'm not wasting my time posting
all
this information to the PR.
One useful thing to find out would be whether, after things stop
working, the process credentials stored in the kernel are still
correct or if they've been garbaged.
As far as I can tell, they aren't garbled I'm pretty sure I've done
this: I open a terminal window, su to my pkgsrc user, run "ls -l",
which
will fail, then run the "jan" login/logout procedure, return to the
(still open) pkgsrc terminal window, and run "ls -l" without any
problems. I'm not 100% sure that I have done this; although I'm pretty
sure. I believe that behavior would be unlikely to work if the
permissions have been garbled. (I can't test it right now, because I
just logged in/out with my normal user, so the permission problem
is not
"active"). I'll be sure to try when it appears again.
When things break, does running
"id" print right or wrong information?
"id" returns the correct information even when the problem is
"active". As does "user info".
So we have permission denied error even we have good information.
Also, does ls -l (or
stat(2)/fstat(2) if necessary(*)) return the right owner/group and
permissions for the affected files?
What the fork? This is a behavior I hadn't noticed before
(though I'm
very certain it has always been there -- I just haven't seen it
until now):
nl102-238-202# su - pkgsrc
$ ls -l
ls: .: Permission denied
$ ls -l update_wip
- -rwx------ 1 pkgsrc users 158 Jun 18 05:15 update_wip
$ ls -l
ls: .: Permission denied
$ ls -l upda*
ls: upda*: No such file or directory
$ ls -l *
ls: *: No such file or directory
$ ls -l .
ls: .: Permission denied
$ ls -l ..
ls: ..: Permission denied
$ ls -l /
ls: /: Permission denied
$ pwd
/home/pkgsrc
<Here I logged in, and then logged out, my "jan" user>
$ ls -l
total 152
- -rwx------ 1 pkgsrc users 219 Sep 8 20:51 checkout_pkgsrc
- -rwx------ 1 pkgsrc users 282 Jun 18 04:31 checkout_wip
- -rwx------ 1 pkgsrc users 173 Sep 8 20:51 update_pkgsrc
- -rwx------ 1 pkgsrc users 158 Jun 18 05:15 update_wip
drwxr-xr-x 1797 pkgsrc users 68608 Aug 11 16:41 wip
$ ls -l /
total 18411
drwxr-xr-x 2 root wheel 512 Sep 5 14:42 altroot
drwxr-xr-x 2 root wheel 1024 Sep 5 16:57 bin
[---]
What about kauth(9) ? Can be this some unfound kauth issue lfs was
not used too much when elad written kauth? Can you ktrace/ktruss
failing ls ?
It's actually only the first few commands which are interesting
(the
rest is old news -- I just wanted to show my cool problem off some
more). Notice that "ls" works when I specify an exact file name(!).
I'll
start working on my speech for when I accept the yearly "wtf?!"-
prize. :(
Also, this is what happens when I run "cvs update -dP" in pkgsrc
(it
appears to actually update the repsitory, although I don't think it
manages to create new directories), but it ends with:
[---]
cvs update: cannot open directory archivers/arc/files for empty check:
Permission denied
cvs update: cannot open directory archivers/arc for empty check:
Permission denied
cvs update: cannot open directory archivers/afio/patches for empty
check: Permission denied
cvs update: cannot open directory archivers/afio for empty check:
Permission denied
cvs update: cannot open directory archivers/advancecomp/patches for
empty check: Permission denied
cvs update: cannot open directory archivers/advancecomp for empty
check:
Permission denied
cvs update: cannot open directory archivers/9e/patches for empty
check:
Permission denied
cvs update: cannot open directory archivers/9e for empty check:
Permission denied
cvs update: cannot open directory archivers for empty check:
Permission
denied
(*) E.g., if once it breaks you can't ls -l, or even call stat()
successfully, you can write a program that opens the file (or
directory) before things break, waits until they do, and then uses
fstat() on that file handle. This should get past any broken
permissions checks. It might also conceivably prevent the problem
from
affecting the file in question...
I'll do that. But I'm pretty sure that it's only file/directory
_enumerations_ which fail. Hmm... I'll try to write a program which
runs
opendir(), lists a few files, and then calls readdir() (or whatever
it's
called), and pauses before continuing. Then I'll instruct it to
continue
once the bug reappears.
Did you see the program I posted in the PR? It show that opendir
(".")
fails when the "bug" is "active"; but I can "cat" files I know to
exist
without problems. I think that's a good place to start looking.
Though I
may be staring myself blind on the opendir() issue. :/
- --
Kind regards,
Jan Danielsson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
iD8DBQFG8IGKuPlHKFfKXTYRCkoZAJ4rGFG9RJDFJNWGMmcc6Kg1Uw72NACfcmNr
2uiH/wQ9dru4AOq1thFZeBY=
=bq1C
-----END PGP SIGNATURE-----
Regards
- -----------------------------------------
Adam Hamsik
jabber: haad@xxxxxxxxxx
icq: 249727910
Proud NetBSD user.
We program to have fun.
Even when we program for money, we want to have fun as well.
~ Yukihiro Matsumoto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFG8PA9lIxPgX3Go0MRApliAKCE0orpVYSlUhqYK7Sq4u+7THc7/wCeP1JP
nBRSswJ771Vlrz/fQU0Ndpk=
=CEaX
-----END PGP SIGNATURE-----
|
|