remaining VMcached code

[LHe496]

Describe the bug
A clear and concise description of what the bug is. Please make sure that your problem appears under the community version of IRAF.

To Reproduce
Steps to reproduce the behavior.

1. Running IRAF on wsl2 with a mirrored network.
2. Run irafcl
3. It takes a long time to open ecl (about tens of minutes)

If possible, please include the used files, or include a link to them.

Expected behavior
A clear and concise description of what you expected to happen.

System details:

• OS:
  Ubuntu Port 22.04 on wsl2 with a mirrored network (Windows on arm, WoA)

  IRAFARCH=linux64

  the arch is aarch64

• Version
  2.17 and 2.18

• Versions of all additionally involved software, i.e. xgterm, PyRAF, sptable,
  both iraf and pyraf

Additional context
Add any other context about the problem here.

Reasons (I guess)
This problem is caused by the VMcache client interface codes which still exist in IRAF. These codes should have been removed on 2.16.

These codes run when the IRAF starts and requests 127.0.0.1:8677 to respond. However, due to the disappearance of VMcached daemon, it would never connect to the daemon. The IRAF would try multiple times but never get an answer (about 30 for me).

On a Linux system that is NOT wsl2 with a mirrored network on WoA, such a process is fine as the system responds with a connection-refused signal (ECONNREFUSED) which does not take much time. However on wsl2 with a mirrored network on WoA(not found on x86 Windows), such a request does not get refused, which causes the IRAF process to wait for the answer until timeout. For this reason, when opening IRAF on wsl2 with a mirrored network, the IRAF process is blocked and when you use top, it sleeps for tens of minutes.

What I mentioned above can be identified using strace to trace irafcl.

The code I found so far is in unix/os/zfiobf.c from line 374 to 871, and the header is unix/os/osproto.h from 31 to 35. I set both vm_enabled and vm_dioenabled to 0 and recompiled IRAF. Now it runs fine on my WoA pc with a snapdragon 8cx gen3 soc. Though it seems to be a problem with Microsoft, I think it's useful not to send tens of network requests to a ghost daemon while starting IRAF.

[LHe496]

The strace log is as below.
log.txt

[olebole]

Thank you very much for digging into this! Indeed the client code is still there and should probably be removed: file caching is nowadays much more flexibly implemented in the OS, and while the server was never compiled by default, it IMO doesn't make sense to keep the client code any more. I will remove that in a PR (or you could, if you have some time now...)