Signal 12 on simple ldd / Linux

[Tuc at T-B-O-H.NET]

> 
> John E Hein wrote at 13:26 -0600 on Sep 27, 2007:
>  > Tuc at T-B-O-H.NET wrote at 14:17 -0400 on Sep 27, 2007:
>  >  > 	I'm finding out that this also ISN'T happening on systems where
>  >  > the Linux install is local, and used local. I'm finding 100% so far that
>  >  > it only happens where /compat is NFS mounted. Is this something someone
>  >  > has ever done, and are there any gotchas that I am running into because
>  >  > of it, or is it just "One of those things you figure out that leads you
>  >  > down the completely wrong path".
>  > 
>  > We mount /compat/linux over NFS.  I have not found any problems like
>  > the one you are having with it after doing so on some boxes for years
>  > (from 4.x to 6.x).  Sometimes, I experience permission problems if,
>  > for instance, the app tries to write to /var/db or something (I don't
>  > export it with maproot=0).  So occasionally I'll add a sym link in
>  > the nfs compat/linux tree to point to a local native directory.
> 
> Is there any file locking that the app might be doing?  If it tries to
> lock a file in /var/db or something, it might try to lock the file in
> /compat/linux/var/db.  I don't remember if 5.3 (which is what you are
> running) supports proper nfs file locking (nfs locking in 4.x just
> always successfully gives out a lock, so if multiple lockers try to
> lock a file, they will all think they own the lock resulting in
> possible file corruption depending on how the lock is used), but you
> do have to make sure lockd and friends are running to get nfs locking
> to work.
> 
	Unfortunately, I really wouldn't know. The binary is from the
"SHA-1 Collision Search Graz" BOINC project. Its closed source. I
had just done testing on an addition I made to the ports tree for
it, when I finally went to test on one of the NFS mounted servers.
Since there isn't source to it, I can't gdb/backtrace a copy. 

	I've run many different apps that do use locking, and
Hylafax oddly enough was the only one that ever presented a locking
issue. I pretty much got blown off on the list for help. I did run
a sample program that was made to test all sorts of locking, and I
never got it to fail. I run lockd/statd on all servers involved
ever since they started to run in mid 2005. 

	I guess I go back to that linux_modify_ldt. On the bad
copy I see :

> 82825: #243()                                    ERR#78 'Function not implemen
te
> d'
> SIGNAL 12 (SIGSYS)
> SIGNAL 12 (SIGSYS)
> Process stopped because of:  16
> process exit, rval = 140
> Bad system call

	which makes me think that it did the #243, and got the not implemented,
and the next command is the system call it didn't understand.  Again,
I could be barking up a wrong tree, especially with this being
limited to the NFS'd machines. If I can find the time, as much as I hate
to, I might pull a "Winderz" and reboot.. I did set the linux up after
the system had started, so maybe something isn't right. It probably has
nothing to do with /proc and linprocfs's, since one machine I use has
both, one only has /proc.....(Oddly, though, the NFS'd systems /proc
DOES NOT have "currproc". Not sure if that means anything to anyone or
anything..........

			Thanks, Tuc