Tina Friedrich <tina.friedr...@diamond.ac.uk> writes: >>> The real and effective user is not root, and never was. Never caused us any >>> problems. The NFS share is exported with root_squash.
If that's the spool area, it means you get world-writable files in it. >> This is quite interesting. And all jobs are running under their inquired >> user account or do you use one common user account for all jobs? > > Jobs are running as the user that submitted them, yes. No common > account. Been set up like that since we installed it. Execd must be able to setuid for that to work, so I assume it is started as root unless there's some fancy way of using capabilities. > Haven't had time to progress with this setup much; is there any > documentation on how the 'inbuild' qrsh etc work? Not past the source, I'm afraid. > As at the moment, my > test installation works, and I can submit jobs (and they run), but > interactive sessions don't work - I get a commlib error: > > [kdf51254@ws112 ~]$ qrsh > error: commlib error: got read error (closing > "cs04r-sc-com99-04.diamond.ac.uk/shepherd_ijs/2") > > Didn't have that problem on my old 6.2 installation :) Check the logs (messages files) for any clues. I don't think it has those symptoms, but there appears to be a race in the threading of the builtin startup that appears on recent Ubuntu, for instance, but doesn't on RHEL5 or 6 in our experience. You can still use ssh per remote_startup(5). -- Community Grid Engine: http://arc.liv.ac.uk/SGE/ _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
