-----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@jabber.org
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-----