iraf.net

Hello,

I have a problem with IRAF that I wonder if anyone could give me pointers to help fix. Basically IRAF is running very slowly (about 10 minutes to startup and 3 minutes to do an imhead. Doing an 'ls' on the other hand is fast. I am running IRAF on my own system (not a system-wide install).

I am running the version 2.16 of IRAF. I have the same problem with the 64-bit version or the combo 32/64 bit version which I have installed both as a local user (myself) and also I tried installing using the root account with the same issue.

Yesterday IRAF was working fine, I had the problem when I came in during the morning and re-installation has not fixed it. Obviously I must have changed something but I don't know what. Yesterday I did a system shutdown without exiting IRAF. I thought the problem was an external package (stella), so reinstalled IRAF without making these packages.

Another thing I have done is remove the chkupdate from the login.cl file but no change. There is always a pipe* file in /tmp when I startup IRAF (does this indicate a problem\$this->_split2($m[0])) and I can't see any /dev/im* or /dev/pi* files.

A top shows my system is not too overloaded. When IRAF starts if I do an 'ls' it is very quick but an imheader takes a few minutes, hence it appears that the disc where both IRAF and the file lie is OK. Both /iraf/iraf and my data are on an external hard disc that seems to be working OK.

Has anyone any clue what I could try and look for? Is there a way of running cl in debug mode?

[jsmoker@pc015042 ~/Iraf]$ ls /iraf/iraf/extern/
configure* README

-rw-rw-r-- 1 jsmoker jsmoker 1005291520 Aug 26 07:22 iraf-linux.tar

[jsmoker@pc015042 ~/Iraf]$ ls -tlr /tmp/
-rw-rw-r-- 1 jsmoker jsmoker 0 Aug 26 08:44 pipe18685

[jsmoker@pc015042 /tmp]$ ls /dev/pi*
ls: No match.
[jsmoker@pc015042 /tmp]$ ls /dev/im*
ls: No match.

[jsmoker@pc015042 ~/.iraf]$ cl (Then wait several minutes)
setting terminal type to xterm...

(then wait a few minutes more)

NOAO/IRAF PC-IRAF Revision 2.16.1 EXPORT Mon Oct 14 21:40:13 MST 2013
This is the EXPORT version of IRAF V2.16 supporting PC systems.

Welcome to IRAF. To list the available commands, type ? or ??. To get
detailed information about a command, type `help '. To run a
command or load a package, type its name. Type `bye' to exit a
package, or `logout' to get out of the CL. Type `news' to find out
what is new in the version of the system you are using.

Visit https://iraf.net if you have questions or to report problems.

*** Initializing SAMP .... No Hub Available

The following commands or packages are currently defined:

dataio. language. obsolete. softools. vo.
dbms. lists. plot. system.
images. noao. proto. utilities.

vocl\$this->_split2($m[0]) cd /media/disk/EDIBLES/AllRaw_HD_23016_Data/data_with_raw_calibs/437_IRAF
vocl\$this->_split2($m[0]) ls UVES.2014-10-28T10:14:47.505.fits
UVES.2014-10-28T10:14:47.505.fits
vocl\$this->_split2($m[0]) date;imhead UVES.2014-10-28T10:14:47.505.fits;date
Wed Aug 26 08:54:20 PET 2015
UVES.2014-10-28T10:14:47.505.fits[2148,3000][ushort]: LAMP,FLAT
Wed Aug 26 08:58:33 PET 2015
vocl\$this->_split2($m[0])

top (in a normal csh)

top - 08:56:38 up 3:50, 7 users, load average: 0.90, 1.10, 1.50
Tasks: 155 total, 1 running, 154 sleeping, 0 stopped, 0 zombie
Cpu(s): 10.7%us, 3.1%sy, 0.0%ni, 84.4%id, 1.2%wa, 0.3%hi, 0.3%si, 0.0%st
Mem: 16344592k total, 5168212k used, 11176380k free, 377824k buffers
Swap: 1048572k total, 0k used, 1048572k free, 3376784k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1551 jsmoker 20 0 639m 23m 11m S 2.0 0.1 1:44.09 gnome-terminal
17933 jsmoker 20 0 15252 1272 904 R 2.0 0.0 0:00.01 top
1 root 20 0 47820 4392 2020 S 0.0 0.0 0:01.21 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:03.55 ksoftirqd/0

If anyone has any ideas of what more I can check it would be good.

Thanks,

Jonathan

The CHKUPDATE command in login.cl sometimes causes problems if it can't make a connection, but since you've removed this and it doesn't explain the IMHEADER delay you can probably rule this out.

To see what's taking the CL so long to startup, I'd recommend using the linux 'strace' command on the binary directly, e.g.

% setenv iraf /iraf/iraf/ # trailing '/' required
% setenv arch ".linux64" # note the dot
% limit stacksize unlimited
% strace /iraf/iraf/bin.linux64/vocl.e

This will tell you more about what's happening at the system level. You can also add a "d_trace" to the top of your login.cl file to have the CL itself do some tracing.

Another thing to test is whether this is specific to the default VOCL binary, e.g. run

% cl -old or % cl -ecl

to use alternate versions. Is there the same delay?

Lastly, the 'pipe*' files are normal but they should be created in your 'uparm' directory (i.e. $HOME/.iraf/uparm for a personal install) and not /tmp. Try deleting them from /tmp/first to see if they are re-created and if so try re-running the install script and doing a new MKIRAF. Note that if /tmp is full all kinds of funny things can happen, so check the disk space as well. Post the strace output (part of it anyway) if nothing obvious jumps out. The 'ls' command may work faster because it is a linux command whereas the IRAF 'dir' command would be read from the external disk, so check the throughput to the disk as well (e.g. a loose cable?).

Dear Fitz,

Thanks a lot for your help with this!

I have tried the following ("solution" at the end).

- Installed the 32-bit version of IRAF on another Linux partition that I have on my computer. This works fine (although I can't access a large disc I would like to).
- Tried the 64-bit version with failsafe window manager and from command line. This has the same issue. Also installing in my home has the same problem.
- Tried running the 64-bit version as root. This still fails.
- Tried alternative versions (cl -old) with the same delay.
- Tried running without thunderbird, firefox. Unplugged my phone that was charging. Still same delay.
- I saw in the output of the strace that some old libraries were being queried, so I unset LD_LIBRARY_PATH. Still the same issue.

In the 32-bit version then the pipe files are created in the ~/.iraf/uparm. However, in the 64-bit version I am still getting the pipe files in /tmp

- I then tried not using the internet cable but wireless. This works fine! Also if I turn off the wireless then IRAF works OK with no delay. With no internet I just get the following warning but no problem:

Welcome to IRAF. To list the available commands, type ? or ??. To get
detailed information about a command, type `help '. To run a
command or load a package, type its name. Type `bye' to exit a
package, or `logout' to get out of the CL. Type `news' to find out
what is new in the version of the system you are using.

Visit https://iraf.net if you have questions or to report problems.

cannot access host 'iraf.noao.edu:80'
*** Using global login file: /home/jsmoker/.iraf/login.cl
*** Initializing SAMP .... No Hub Available

So, somehow there is an issue with the internet when using my cable.

The strace is below but I have a good work around now. Thanks a lot again for your help.

Best regards,

Jonathan

open("/lib64/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\2\1\1\3\$this->_split2($m[0])\1\320\20"..., 832) = 832
fstat(6, {st_mode=S_IFREG|0755, st_size=31656, ...}) = 0
mmap(NULL, 2121952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b2eb75f5000
mprotect(0x2b2eb75fa000, 2097152, PROT_NONE) = 0
mmap(0x2b2eb77fa000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x5000) = 0x2b2eb77fa000
close(6) = 0
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 6
read(6, "\177ELF\2\1\1\3\$this->_split2($m[0])\1\2609"..., 832) = 832
fstat(6, {st_mode=S_IFREG|0755, st_size=106632, ...}) = 0
mmap(NULL, 2198088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) = 0x2b2eb77fc000
mprotect(0x2b2eb7812000, 2093056, PROT_NONE) = 0
mmap(0x2b2eb7a11000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0x15000) = 0x2b2eb7a11000
mmap(0x2b2eb7a13000, 6728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2b2eb7a13000
close(6) = 0
mprotect(0x2b2eb7a11000, 4096, PROT_READ) = 0
mprotect(0x2b2eb77fa000, 4096, PROT_READ) = 0
munmap(0x2b2eb5c99000, 146447) = 0
socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("AAA.BBB.CCC.DD")}, 16) = 0
poll([{fd=6, events=POLLOUT}], 1, 0) = 1 ([{fd=6, revents=POLLOUT}])
sendto(6, "I\3\1\1\tlocalhost\3ads\3eso\3o"..., 39, MSG_NOSIGNAL, NULL, 0) = 39
poll([{fd=6, events=POLLIN}], 1, 5000) = 1 ([{fd=6, revents=POLLIN}])
ioctl(6, FIONREAD, [55]) = 0
recvfrom(6, "I\3\205\200\1\1\tlocalhost\3ads\3eso\3o"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("AAA.BBB.CCC.DD")}, [16]) = 55
close(6) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
connect(6, {sa_family=AF_INET, sin_port=htons(8677), sin_addr=inet_addr("AAA.BBB.CCC.DE")}, 16) = ? ERESTARTSYS (To be restarted)
--- {si_signo=SIGWINCH, si_code=SI_KERNEL, si_value={int=284849952, ptr=0x7fff10fa7720}} (Window changed) ---
connect(6, {sa_family=AF_INET, sin_port=htons(8677), sin_addr=inet_addr("AAA.BBB.CCC.DE")}, 16) = -1 ETIMEDOUT (Connection timed out)
close(6) = 0
stat("/tmp/pipe8857", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
fstat(5, {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
getuid() = 1000

Thanks!

Jonathan

The problem seems to be in resolving a DNS name somewhere. Check that your /etc/hosts file contains an entry for 'localhost' with an address of 127.0.0.1, e.g.

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4

Your wireless connection is probably using DHCP to get a network address whereas your wired connection is probably a fixed IP. There may be some problem in your network setup, e.g. the wrong DNS servers. Does a command like

% host www.eso.org

resolve quickly? If your machine has a fixed name, does it resolve?

Hi,

Thanks again. The host www.eso.org resolves fine on the cable (I have a floating IP name). I'll check up with our sys-admin people if anything changed and post here if the reason is found on our side.

Best regards,

Jonathan