I did compiled it as :
[root@eax adam]# gcc test3.c -g -static -o test3.s.g
[redhat 4.2,libc.so.5.3.12]
If I run it on this system [2.0.33], it execs fine:
[root@eax adam]# strace ./test3.s.g
execve("./test3.s.g", ["./test3.s.g"], [/* 21 vars */]) = 0
personality(PER_LINUX) = 0
geteuid() = 0
getuid() = 0
getgid() = 0
getegid() = 0
setuid(500) = 0
sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}) = 0
sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}) = 0
sigprocmask(SIG_BLOCK, [CHLD], []) = 0
fork() = 4983
wait4(4983, #########
No matter how much you do you never do enough.
#########
[adam@eax adam]$ exit
exit
[WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 4983
sigaction(SIGINT, {SIG_DFL}, NULL) = 0
sigaction(SIGQUIT, {SIG_DFL}, NULL) = 0
sigprocmask(SIG_SETMASK, [], NULL) = 0
--- SIGCHLD (Child exited) ---
_exit(0) = ?
If I exect it on 'client' [same /usr, NFS mounted root dir,
hand-made copy of root dir / -> /tftpboot, 2.0.33pre11 ]
I get this:
[root@bea /root]# strace ./test3.s.g
execve("./test3.s.g", ["./test3.s.g"], [/* 18 vars */]) = 0
personality(PER_LINUX) = 0
geteuid() = 0
getuid() = 0
getgid() = 0
getegid() = 0
setuid(500) = 0
sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}) = 0
sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}) = 0
sigprocmask(SIG_BLOCK, [CHLD], []) = 0
fork() = 9943
wait4(9943, [WIFEXITED(s) && WEXITSTATUS(s) == 127], 0, NULL) = 9943
sigaction(SIGINT, {SIG_DFL}, NULL) = 0
sigaction(SIGQUIT, {SIG_DFL}, NULL) = 0
sigprocmask(SIG_SETMASK, [], NULL) = 0
--- SIGCHLD (Child exited) ---
--- SIGBUS (Bus error) ---
+++ killed by SIGBUS +++
I did try compile it statistically with libc2.0.5 from redhat 5.0
libc-5.4.33 from debian1.3 and I'm experiencing the same problem,
so I don't think it is libc specific.
On the other hand I'm experiencing this problem for pretty long
time, half of year or so, so it is not specific to this
particular kernels too.
To make things even more strange, it did worked for me fine
if I would use Slackware based system.. but I don't have that
one anymore.
This or other way, as I understand it fails on fork() which
this or other way is just an wrapper to system call in kernel.
To recap, the only major difference between those two is that
on the 2nd one the system was *netbooted* and it has *nfs mounted root*
directory.
If I do everything as root it works fine, but any attempt of switching
to non-root users will fail. Say login will report 'no home dir',
su will say 'can't exec /bin/bash' .. so the above are attempts to
nail the problem.
-Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu