iraf.net

Hi allHas anyone encountered same problem as I? I think my iraf or ds9 has been updated and now display doesn't work. I use Debian and iraf and DS9 packages maintained by Justin Pryzby.I use iraf with python front-end pyraf. DS9 starts normally with command !ds9& and it works if I open fits-files directly from its menus. However when I type command display image.fit 1 it gives me following error first time.Killing IRAF task `display'
Traceback (innermost last):
File "<CL script CL1>", line 1, in ?
iraf.display('image.fit', '1', _save=1)
IrafError: Error running IRAF task display
IRAF task terminated abnormally
ERROR (742, "Cannot open device (node!imtool,,512,512)")If I start DS9 again and type the same command error will be:
Error: IIS iisIO problems.DS9 crashes in both.I also tried display at original iraf and got this
PANIC in `/usr/lib/iraf/iraf/bin/x_tv.e': Memory has been corruptedI would be greatfull of any solution.-Juho Pekka Vehviläinen

Do you get a 'memory corrupted' error from any task, e.g. "cl> implot dev$pix"? If so then you're probably seeing the "stacksize problem" in newer linux kernels. What's needed is to do something like[code:1:23d2918c53]
linux% limit stacksize unlimited (for c-shell)
linux% ulimit -s unlimit (for bash shells)
[/code:1:23d2918c53]The normal 'cl' startup command will do this automatically however this was only fixed in the most recent PyRAF version so you may need to update that if you're using an older version. Otherwise, a 'cannot open device' means it isn't finding the display server for some reason (e.g. DS9 didn't open the sockets). You might also try a more recent DS9 from the SAO site rather than the Debian package version as well.I don't know for sure whether this fix is in the Debian package version (which I believe is now orphaned and not being maintained), for V2.12.2 and later systems it should be part of the normal system. Hope this helps.Cheers,
-Mike

All right, problem solved.I updated DS9 from the SAO site. Most recent version of it is 4.0b9 and Debian testing has version 4.0b7-1.2. SID or unstable has version 4.0b7-1.3. I don't know about that, but this b9 seems to work. DS9 is easy to update manually as it's small program.fitz, thank you for helping (again)!

I'm having exactly the same problem as [b:e15d4030a8]moppi[/b:e15d4030a8] did except I'm running Kubuntu (Edgy Eft).If I try to display an image I get[code:1:e15d4030a8]ERROR: Cannot open device (node!imtool,,512,512)
[/code:1:e15d4030a8]
I've tried all variations on the -fifo_only -unix_only -port_only thing and various attempts will just result in segmentation faults, ds9 crashes, or complete system freezing. Once the fifo pipes were even deleted. Any ideas? I'm using DS9 4.b10. The DS9 FAQ (http://hea-www.harvard.edu/RD/ds9/faq.html#IRAF) mentions this the problem too but their "solution" does nothing for me.Depending on what I'm trying, I also get [code:1:e15d4030a8]Error: IIS iisIO problems [/code:1:e15d4030a8]as an error that just repeats over and over (and will eventually freeze the machine).The normal pipes are there in /dev so I don't know why it's having trouble.Mike, I also tried the "setenv DEBUG_IIS 1a" trick you once explained to somebody. I didn't see any output in the window. But there's a socket file called .IMT1000 in the /tmp directory.UPDATE: If I start ds9 with "ds9 -unix", it will display the dev$pix image (I don't think it was doing this before I tried the DEBUG trick but not sure) but still puts that repeating "IIS iisIO problems" message in the window that started ds9. However, "ds9 -unix_only" does not work. Totally confused here.Jason Quinn

The default display connection is over the unix socket (i.e. the /tmp/.IMT1000 file you mentioned). The fifo pipes and inet socket are opened by the display server as alternate inputs but the IRAF side will use the unix socket unless told to do something else by either the dev$graphcap entry for the stdimage, or a unix IMTDEV environment variable. Since the unix socket is based on the userid be sure both IRAF and DS9 were started by the same user (and that neither is a setuid-root binary, i.e. an 'ls -l' doesn't show an 's' in the permissions field).If you see no output with the DEBUG_IIS trick then the connection wasn't made at all to the server. You can force the use of the fifos by defining[code:1:468c030464]unix% setenv IMTDEV "fifo:/dev/imt1i:/dev/imt1o"
unix% ds9 -fifo_only & # start a DS9
unix% cl
[/code:1:468c030464]If this works the problem is in the unix socket, e.g. a permissions problem, wrong userid, can't write to /tmp, etc. Also be sure to test using dev$pix as the image, in the original post a memory corrupted could possibly be a bad pixel mask used automatically if specified by a BPM header keyword.For both posts I'm assuming this is NOT the Debian package of IRAF which has several known issues. Hope this helps.Cheers,
-Mike

[quote:6212210936="fitz"] be sure both IRAF and DS9 were started by the same user (and that neither is a setuid-root binary, i.e. an 'ls -l' doesn't show an 's' in the permissions field).[/quote:6212210936] Checked. No 's' is there.[code:1:6212210936]unix% setenv IMTDEV "fifo:/dev/imt1i:/dev/imt1o"
unix% ds9 -fifo_only & # start a DS9
unix% cl
[/code:1:6212210936]This resulted in the device error:
[code:1:6212210936]
ERROR: Cannot open device (node!imtool,,512,512)
[/code:1:6212210936]
[quote:6212210936="fitz"]Also be sure to test using dev$pix as the image[/quote:6212210936]Correct, I am using the dev$pix image.[quote:6212210936="fitz"]
For both posts I'm assuming this is NOT the Debian package of IRAF which has several known issues. Hope this helps.[/quote:6212210936]I'm using the patch2a generic lnux version.Who should own the FIFO pipes? root or iraf?Jason

The /dev fifo pipes should be owned by root with permissions 666 (i.e. -rw-rw-rw).
Also, I was mistaken earlier: The unix socket is the default indeed, however IRAF will fallback to the fifo's if it cannot be opened for some reason. The IMTDEV string however overrides everything.I also seem to remember that a unix 'host' or 'mach' environment variable can mess with things, 'host' should be something like /iraf/iraf/unix/ and not the machine name.-Mike

[quote:5bff6f2567="fitz"]The /dev fifo pipes should be owned by root with permissions 666 (i.e. -rw-rw-rw).
Also, I was mistaken earlier: The unix socket is the default indeed, however IRAF will fallback to the fifo's if it cannot be opened for some reason. The IMTDEV string however overrides everything.I also seem to remember that a unix 'host' or 'mach' environment variable can mess with things, 'host' should be something like /iraf/iraf/unix/ and not the machine name.-Mike[/quote:5bff6f2567] The FIFO pipes are created with 777 permission. I changed them to 666 but have the same problems. Both the host and mach variables are unset but I set them to /iraf/iraf/unix and some other values but to no avail. I'm running out of ideas. I'm so close to having IRAF run on this system but yet so far. I saw that some people fixed (?) the problem by upgrading from 4.0b7 to 4.0b8. I'm going to try to downgrade from 4.0b10 to 4.0b8 and see what happened if I can find a copy.Jason[color=red:5bff6f2567]UPDATE: [/color:5bff6f2567] Possible breaktrough. There's a 4.0b10.1 version at the ds9 download site (discovered by snooping the ftp tree). I can get dev$pix to display! So this might be a ds9 problem again. Let me play around with it for a while and see how it works (I'm wise enough to know about getting excited too quickly). Thanks for your thoughts, Mike. You're an invaluable source of information. You once mentioned to me that a 24-bit version of Ximtool was in the works. Any word on that? I actually prefer ximtool to ds9 so it would kick butt to be able to use it again.