I ran into the issue that Daniel Quinlan posted about back on 18 May 2010. His posting is available at
http://lists.apple.com/archives/unix-porting/2010/May/msg00000.html
(I would reply to his posting but I just joined this list and I can't see any obvious way to reply to an old posting)
A quick summary of the issue is that background processes running on a Snow Leopard system sometimes get themselves into a state where they are unable to do DNS lookups. The error that they get is
could not lookup DNS configuration info service: (ipc/send) invalid destination port
As un-luck would have it, I ran into this issue today with a background critter that I run on a remote Snow Leopard system. I wrote the following shell script to try to diagnose the issue:
=== start script ===
#!/bin/sh
ADDR=replace.this.with.some.valid.name.resolvable.by.dns
while true ; do
date
ping -c 1 $ADDR
sleep 3
done
=== end script ===
I launched this script from an ssh session as follows:
./myScript > myScript.out 2>&1 &
I then launched a "tail -f myScript.out" from a different ssh session. Everything was working as one would expect.
I then logged out of the first ssh session. The output of the "tail -f myScript.out" command immediately started to include the above noted error message and the ping commands started to fail.
I then terminated the "tail -f myScript.out" command, logged back into the Snow Leopard box (in order to have two active sessions), killed the myScript script that had been running in the background and launched it again using the nohup command:
nohup ./myScript > myScript-nohup.out 2>&1 &
I then started up a "tail -f myScript-nohup.out" in the other ssh session to watch the results of the nohup variant. Everything was working as one would expect.
I then logged out of the ssh session which had been used to launch myScript via nohup. Unlike the first time, the output of the "tail -f myScript-nohup.out" command revealed that the ping commands continued to work.
The bottom line would appear to be that background processes which are launched using nohup or, presumably, which ignore the HUP signal programatically do not suffer from the dreaded
could not lookup DNS configuration info service: (ipc/send) invalid destination port
issue.
I will be the first to admit that I have not rigorously tested this apparent workaround. That said, launching my background critter using nohup seems to have made the issue go away. Also, I should probably add that some background programs might not work properly if they are launched with the HUP signal being ignored (either via nohup or programatically). Consequently, anyone who contemplates using the workaround described above is strongly advised to CAREFULLY test that their background critter is happy to operate while HUP signals are being ignored.
-Danny
P.S. The remote Snow Leopard box is running a fully patched Mac OS X 10.6.4. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden