I think that hard-coding the hostname could be a problem, yes--the point of the hostname is that since there are multiple machines mounting the same NFS directories, each one will have its own temporary lock file, to be linked to the main lock file. When they all have the same hostname (because it's been hardcoded), that won't work, and I *believe* it will render the locking useless.

So I would suggest asking sonic.net to fix the hostname() problem (with Sys::Hostname). It's a standard Perl module. What was the error you got? Just that the hostname could not be determined?

I don't actually see the point of having multiple lock files - it seems to me that there should be one per database, but creating a temp and linking it to a master lock file probably accomplishes that, in a round-about way.

What directory are the lockfiles created in? I don't see them anywhere.

OK, I guess that makes sense. It turns out that Sonic's perl is below the level you require for MT, which may be why the hostname() call is failing. So I've fixed my blog to one of their servers by fiddling with the DNS, and I've hardcoded the $hostname to that particular server.

It's kindof weird that Kelsey gave you some code that won't run on their systems, but that's Sonic for you.

Oh, okay. So does the code work fine when you remove the -T switch?

I'm getting the same error message (Cannot get host name of local machine at /usr/local/lib/httpd/cgi-bin/marina/mt/lib/MT/ObjectDriver/DBM.pm line 47 ), and yes, I am on Sonic too. So what do I need to do to fix this problem? Do I edit something somewhere to remove a -T switch? If so, where?

I have the UseNFSSafeLocking enabled in mt.cfg. This problem only showed up after I enabled that option. I cannot save new entries or create new categories with it enabled. When I turn the flag off (i.e., comment it out again in mt.cfg), everything works again. However, I am worried that the database corruption problem will rear its ugly head™.

Also, BubbaDude, why did you say that Sonic does not have the latest version of Perl? According to mt-check.cgi, Sonic has version 5.00502. It says in the MT 2.0 installation guide that version 5.004_04 or greater will work. And I disagree with the "that's Sonic for you" comment. I have been with them since 1996, and find their service and technological knowledge to be outstanding.

Marina
The Lighthouseonline and CatMom.com

Thanks very much for the information! I will check and test.

True, Sonic's bandwidth is small. I get about 11,000 hits to my Web site a month, but I haven't exceeded my quota yet. I think the hits are mainly from people viewing my articles (my Web site has been around for many years, and is linked to from a lot of places), especially my article on the potential health hazards of clumping clay kitty litters. As far as I can tell (though my Web log is new and young and this may change), about the only person who has responded to my blog is a cousin of mine. :-)

Marina

I installed 2.0 at Sonic.net, the ISP that uses NFS which causes the file-locking problems. Right off the bat, I ran into a problem with the call to hostname failing in some of the magic code for safe locking. I don't know why the call fails, but just to work around it I changed the code to use a hard-coded string that happens to correspond to one of the Sonic hostnames. With that squirrely mod, it runs and time will tell if the database corruption returns.

If this going to cause me a problem? Sonic has three different web servers sharing the same nfs server, BTW.

Thanks in advance,

Richard Bennett

The error message is: "Cannot get host name of local machine at /usr/local/lib/httpd/cgi-bin/calbubba/mt2/lib/MT/ObjectDriver/DBM.pm line 47"

I've reported it to Sonic.

This is based on the code that Kelsey Cummings from sonic.net sent me. There aren't multiple lock files--there are multiple temporary files, and only one temporary file can be linked to the lock file at one time. If a host tries to link its temp file to the lock file, it will fail if the lock file is already linked. If it's not linked, the link will succeed, and the host will gain the lock.

The lock files are deleted, unlike the flock() locks, which stay around, because it's simply a bit easier to keep them around. Since the presense of the lock file in the NFS-safe locking indicates a lock, those lock files *cannot* stick around.

It turns out the hostname() call fails because of the -T switch. See man perlrun and man perlsec.

Seems to work OK, but I'm backing-up the databases every day in case it doesn't.

The -T switch is something for your development phase that you want to turn off for production use, as I understand it.

Well, sort of, yes... it's not really a development flag, but we are going to turn it off in the future for releases.

In the first line of about three of the MT cgi scripts (like mt.cgi), you'll find something that reads:

#!/usr/bin/perl -wT

Take the 'T' off the end, and you're cool (I don't remember which ones were like this, but check all the *.cgi files in the directory where you have mt.cfg and you'll find them.) Don't run mt on Sonic without safe locking, because your databases will get corrupted in the course of time and you'll be screwed.

Sonic has apparently just upgraded their perl - on Friday it was version 5.004_03. The latest version of perl is 5.6.

Sonic is, in some ways, a good little ISP; they're certainly better than Verio. But they do have a very quirky installation, and they aren't at the latest release of Linux or of perl. They've been talking about upgrading so long that the targets of their Linux and perl upgrades are now out of date.

They also have a pretty severe bandwidth quota (1 GB a month) that are too tight for me, since I get linked by Instapundit about twice a week, but they're OK for less-traveled blogs. It doesn't appear that Sonic is really interested in hosting blogs.