Bugzilla – Bug 3410
globus_xio writev() error
Last modified: 2005-08-03 16:47:54
You need to log in before you can comment on or make changes to this bug.
I've checked out 2005-05-23 a GT4 from head-of-CVS, and compiled it. Some client tool dies with the following error: # su globus -c /opt/globus/default/sbin/globus-start-container-detached bash: /root/.bashrc: Permission denied # never mind Globus container started. PID: 30398 # tail -2 container.log [50]: https://128.135.152.241:8443/wsrf/services/CASService [51]: https://128.135.152.241:8443/wsrf/services/ManagedJobFactoryService $ grid-proxy-info ... type : RFC 3820 compliant impersonation proxy strength : 1024 bits timeleft : 11:59:46 $ globusrun-ws -submit -S -s -c /bin/date Delegating user credentials...Failed. globusrun-ws: Error trying to delegate globus_soap_message_module: Failed sending request ManagedJobFactoryPortType_GetMultipleResourceProperties. globus_xio: System error in writev: Invalid argument globus_xio: A system call failed: Invalid argument A failure in writev(2), hmmm! The system is a RH9: # uname -a Linux griodine.uchicago.edu 2.4.30 #1 SMP Mon Apr 11 12:52:40 CDT 2005 i686 i686 i386 GNU/Linux # su globus -c 'gcc -v' Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
*** Bug 3407 has been marked as a duplicate of this bug. ***
See bug#3407 that also pre-WS is affected.
I think i have fixed this is CVS. Can you please do the following: grep IOV_MAX $GLOBUS_LOCATION/include/gcc32dbg/globus_config.h and send back the output?
Here from the failed CVS checkout (yesterday): /opt/globus/20050525/include/gcc32dbg $ grep IOV_MAX globus_config.h #define IOV_MAX sysconf(_SC_IOV_MAX) HOWEVER, here from the April 30th checkout that works: $ grep IOV_MAX $GLOBUS_LOCATION/include/gcc32dbg/globus_config.h #define IOV_MAX sysconf(_SC_IOV_MAX) Note, no difference...
I made the fix yesturday, and it is a fix to an autoconf script so you need to reconfigure core and rebuild everything to see it. That is the symptom i was expecting to see, so i am fairly sure it is fixed in cvs. Please do a fresh chcekout and fresh build and let me know what that grep results in. If it is still the same i will need access to the system.
OK, I've checked out everything according to Stu's instructions, compiled and installed, and the output from the grep is the same: $ echo $GLOBUS_LOCATION /opt/globus/20050526 $ grep IOV_MAX $GLOBUS_LOCATION/include/gcc32dbg/globus_config.h #define IOV_MAX sysconf(_SC_IOV_MAX) Soooo (it's a RH9), you want an account. Please send a openssh2 public key you want to use to log onto griodine via separate email...
Did you checkout from the trunk or a branch. The fix is only in the trunk.
I am not that versed with CVS, so I don't understand your question. However, what I did is the following (reduced to main steps): rm -rf packaging cvs co -r globus_4_0_branch packaging >> $log 2>&1 cd packaging ./fait_accompli/installer.sh >> $log 2>&1 which=`/bin/ls -d gt*-all-source-installer` cd $which ./configure --prefix=$GLOBUS_LOCATION --enable-wsgram-condor \ --enable-rls --with-iodbc=$GLOBUS_IODBC_PATH >> $log 2>&1 make >> $log 2>&1 make install >> $log 2>&1 Stu asked me this morning to use the -r tag!
Sorry Jens. The bug got reported from the trunk, so that is where buzz fixed it. You switched to the branch, because that is the code that you/we should be testing/using. The bug then also showed up in the branch, but Buzz was looking for confirmation from the trunk.... Ugh. Buzz will test and commit the same fix to the branch. Jens: you can continue to work in the branch and hopefully things work after buzz's commit.
sorry i have added it to the 4.0 branch now also.
I am to redo the steps from #8 now? Or revert to my original cvs checkouts without the -r tag, and redo #8? Thanks, Jens.
OK, I've recompiled the branch, and rerun my tests. It works now. I've also tested with a larger workflow, and results look promising: http://griodine.uchicago.edu/ivdgl1/100x1x1200/run0001/ I'll mark it as fixed.
