Compilations create intelremotemonfifo.500 file

Compilations create intelremotemonfifo.500 file

With update 2 of the Composer XE Fortran (and C++) compilers on a RedHat 6.5 32-bit system, the compilation process leaves a fifo file of the form

 

prw-------.   1 fitchk kklsim      0 Mar 13 17:19 intelremotemonfifo.500

in the directory where the source file exists.  Normally, I wouldn't care, but when you try to do a grep "something" *, the grep hangs when it gets to the fifo.  It's annoying to have to delete this file manually.  How can I make the compiler either a) not create the fifo in the first place, or b) cleanup after itself once the compilation is complete.

I gather that this is part of the remote monitoring feature, which I opted not to use when I installed update2.  I also verified that monitoring is disabled using the "ism" tool.

 

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The pipe is created either in the directory appearing in the TMPDIR environment variable or /tmp if the variable is not set. Maybe you can adjust the variable’s setting to direct the file away from your source directory.

The pipe is associated with the monitoring and created and reused for subsequent compilations from what I can discern; however, I do not know whether it is necessary to create/remove it for each compilation. I submitted a request w/Development for consideration of having the compiler check whether monitoring is active in determining whether to create/open the pipe. I will keep your post updated with their response.

(Internal tracking id: DPD200254448)

Thanks for the quick response.  Our make recipies are defining TMPDIR to point at the source file directory, hence the observed behavior.

We are porting code from a different O/S & compiler to Linux/Intel Fortran & C.  Since TMPDIR is "overloaded" (it controls scratch file generation, etc.) and I don't want to mess with a working system, I've opted to add a delete of the intelremotemonfifo fifo as the last step in the make sequence, and this solves my problem.

An alternative to an active compiler check for active monitoring might be to simply replace the /opt/intel/.../libintelremotemon.so library with a dummy "noop" one when the user opts not to participate in the monitoring.  In our application, where the computers will not be connected to the Internet once deployed, the remote monitoring feature will never get the chance to "phone home".

Leave a Comment

Please sign in to add a comment. Not a member? Join today