Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I have a job I ran using dmtcp that has an extra output file it creates in addition to the STDOUT and STDERR files. The script that I am converting to use dmtcp (from blcr) has a stats routine that does an lsof every 10 minutes to check on the sizes of the various output files (among other things). When I run using blcr, I see all 3 write/output file handles in the lsof output (STDOUT, STDERR, and the extra file that the executable creates). However, when I run using dmtcp, even though the file is getting created and the process appears to be functioning properly, that regular write file handle never appears to show up in the lsof output as being written to. I logged into the node to do a manual lsof while the job was running and it shows that extra file as being read from instead of written to:
meme.bin 30157 rwleach 0r REG 0,22 180224 1209397114
That's the extra file I expect to see being written to. I unfortunately do not have the lsof output from the blcr run to make a direct comparison in case it also shows a read from that file handle (I just discovered this issue, so I haven't yet tested blcr to determine the lsof output, and figured I would first ask how dmtcp treats new output file handles that the process creates), but I know that under blcr, the file appears in lsof as a REGular write file handle because my stats routine finds it and spits it out in its stats.
I did a manual lsof on the dmtcp coorinator as well and could not find the write file handle that I expect to see there either. Assuming I haven't made some sort of dumb mistake in my incorporation of dmtcp, is dmtcp doing something with my write file handle? Where should my stats routine look for it?