Eudora no longer <<Dominant>>

Late last week, I began to get this error from Eudora on my Mac:

"error while performing unknown task for <<Dominant>>"

My sponsored version of Eudora was trying every two minutes to contact adserver.eudora.com to fetch an updated advertisement. The problem is, Qualcomm no longer develops nor supports Eudora, and apparently turned off the adserver server. Without a response from the server, the Eudora client would pop up an error every couple minutes.

As a quick-n-dirty patch, I put an entry in my Mac's /etc/hosts file for "adserver.eudora.com" with an IP number that belongs to one of our local web servers and restarted Eudora. I haven't received the error since then. The access log on the web server shows that my Mac is requesting:

"POST /adjoin/playlists HTTP/1.0" 404 285

The web server is obviously replying with a 404 error, but at least Eudora doesn't timeout now. Not the best fix, but the best for now.

Back to that Pesky Virtual Frame Buffer

Sigh. While my procedures with the Solaris virtual frame buffer (see previous posts) has usually been working okay, I had to modify the kill command to make it definitely exclude the grep process even though it should have excluded it anyway - very weird:

/usr/bin/kill `ps -ef | grep Xsun | grep -v grep | grep ":5" | awk '{print $2}'`

The user reports that they're occasionally getting this error in their logs:

fstat: Bad file number
(failed to stat vfb)
stat: No such file or directory
(failed to stat vfb)
fstat: Bad file number
(failed to stat vfb)
stat: No such file or directory
(failed to stat vfb)
X connection to localhost:5.0 broken (explicit kill or server shutdown).

This is due to the VFB running in a local Solaris zone. According to a post I found at http://forum.java.sun.com/thread.jspa?threadID=5233796&tstart=120 one can add /dev/winlock to the local zone this way to solve those errors:

"Steps to add the pseudo device '/dev/winlock' to the local zone:

As a superuser in the global zone,

1. Add the '/dev/winlock' pseudo device to the local zone:
global# zonecfg -z
zonecfg:zonename> add device
zonecfg:zonename:device> set match=/dev/winlock
zonecfg:zonename:device> end
zonecfg:zonename> exit

With this, the local zone will have access to '/dev/winlock' device.

2. Reboot the local zone
global# zoneadm -z reboot

Once the local zone is rebooted, '/dev/winlock' will now be available in the local zone."

I've made the change in the zone configuration so it will take effect the next time I reboot. I can see it now - I'll reboot, the instructions above will have been wrong, the zone won't come up, and it'll take me a half hour to remember what changes I made... hopefully I've made enough notes that I'll remember it.