I think you need to show a little more of the truss. If I am interpreting this correctly, process 15957 is tst, 15982 is the reading process of rsh, and 15992 is the writing process of rsh. So, what I see 15992 doing is trying to read from the stdin from the popen in tst, but since popen had a mode of "r", there is no stdin, so it got a EOF (i.e. 0) on the first read. Since there is nothing to send, it then called the shutdown to shutdown the outgoing half of the connection.
The process 15982 got a buffer of data from the remote system, and then wrote it to stdout, as it should. Shortly after that, it got an EOF on the stdout from the remote connection, so it killed the write process and exited, as it should. We also see process 15957 read the buffer of data. Since that is where the truss ends, there is no way to tell what it did with it after that. So, either the tst process got the buffer but then didn't print it, or 15957 was not the tst process. It might be the su process. In any case, I can't tell from just a snippet of the code and a snippet of the truss. Daniel Morrison wrote: > solaris 10 Sparc (10/08) Studio 12 compiler > > tst.c (snippet) > > strcpy(syscmd, "/sbin/su w001 -c \"/usr/bin/rsh machB /usr/bin/ls\""); > pptr = popen(syscmd, "r"); > while (fgets(line,sizeof(line),pptr) != NULLP) > fprintf(logptr, "%s\n", line); > pclose(pptr); > > - When tst is run from root - (w/no env) works fine > - When tst is run from background - (w/no env) works fine > - When tst is run from cron - fails to read any data > > created machB:/tmp/tst.sh to test su & rsh... > #!/bin/sh > /usr/bin/ls > /tmp/ls.capture > > - substituted /usr/bin/ls with /tmp/tst.sh in rsh (above) > - output to log fine, so, there isn't anything wrong with env or permissions, > etc > > next... > - ran truss on tst from root > - ran truss on tst from cron > > Listings are essentially the same, except ENOTTY in various places > > But - the KEY is - the truss (from cron) shows a buffer of data coming back > from the remote 'ls' command WORKS - but the socket is shutdown before the > buffer can be read! > > 15992: read(0, 0xFFBF35DC, 51200) = 0 > 15982: read(4, " M a p p e r\n a d m i n".., 51200) = 83 > 15982: write(1, " M a p p e r\n a d m i n".., 83) = 83 > 15992: shutdown(4, SHUT_WR, SOV_DEFAULT) = 0 > 15957: read(3, " M a p p e r\n a d m i n".., 5120) = 83 > 15982: pollsys(0xFFBF3398, 1, 0x00000000, 0x00000000) = 1 > 15982: read(4, 0xFFBF35DC, 51200) = 0 > 15982: kill(15992, SIGKILL) = 0 > 15982: _exit(0) > > Mapper\nadmin\n... is the CORRECT buffer of file names on the remote > directory. So everything succeeds - except being able to 'read' the contents > of the buffer. > > I see the write(1, ...) which should be a write to stdout, but it is followed > by the shutdown(). > > I have tried a fread() - instead of fgets(), but no difference. > > So - the question is - how do I prevent socket from closing early in this > scenario. I've tried everything I can think of. (I have tried -n option for > rsh, no joy). > > Appreciate any insight into what is triggering this problem. > > Thx! > Dan -- blu "Murderous organizations have increased in size and scope; they are more daring, they are served by the most terrible weapons offered by modern science, and the world is nowadays threatened by new forces which, if recklessly unchained, may some day wreak universal destruction." - Arthur Griffith, 1898 ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
