I assume CentOS is some kind of Linux? The email below is geared toward
Linux.
> File busy try again later!
> Failed while attempting to update_file() the assign file
> Error. Failed to add domain to assign file
> Error: Could not update file
Let's see if we can use the source to figure out what's wrong.
In vpopmail.c, the code is trying to append a line to the assign file.
To do this with FILE_LOCKING defined, the "update_file" routine needs
to open and lock "assign.lock". If it doesn't, it complains:
"Failed while attempting to update_file() the assign file"
The update_file routine calls get_write_lock to do its dirty work.
Here's the routine in file_lock.c:
int get_write_lock( FILE *fs )
{
int try = 0;
while(write_lock(fileno(fs), 0, SEEK_SET, 0) < 0)
{
if (errno == EAGAIN || errno == EACCES || errno == ENOLCK )
{
/* there might be other errors cases in which
* you might try again.
*/
if (++try < MAX_TRY_RLOCK) {
(void) sleep(2);
continue;
}
(void) fprintf(stderr,"File busy try again later!\n");
return(-1);
}
return(-2);
}
return(0);
}
The write_lock() routine is a wrapper for fcntl(). If you look at
the fcntl(2) man page, it lists many reasons why it would fail.
Based on your second email, it's not permissions. Some other program
must have a lock on the file and is not letting go, or there's some
other odd problem (NFS? extended attributes?).
I have a few suggestions to help debugging:
1. Run "strace -f /home/vpopmail/bin/vadddomain ...etc...".
Look at the output right before the printf of the error messages
for the return value from fcntl.
2. Run "lsof assign.lock" after it fails to see if there are any
other processes that have the file open. This would be done on
both the client and the server.
3. Add the following line before the line that has "++try < MAX_TRY_RLOCK":
(void) perror("Debug write_lock: ")
Then recompile vpopmail, install it, and try it again (don't forget
to make backups!). You'll hopefully get a reason for the locking
failure printed when it happens again.
4. Restart the NFS client and the NFS server and try again (stale lock).
Also, something you might need to do is make sure your NFS server
doesn't clobber UID names. I noticed in one of your emails that
"assign.lock" was owned by "nfsnobody". The export options on the
NFS server should use "no_all_squash,no_root_squash,async,rw".
On most distros, "no_all_squash" is the default option, but your
distro might have it set the other way.
Other NFS stuff:
1. The client needs to use NFS V3 for fcntl locking to work.
See this article:
http://www.quepublishing.com/articles/article.asp?p=23618&seqNum=4
2. Is nfslockd running on the client?
3. Is the NFS client and NFS server running the same OS? If not,
could there be some compatability issues?
Hope this helps.
--
Eric Ziegast
PS: If all else fails, install vpopmail on the NFS server and run the
administrative commands (vadddomain, vadduser, etc.) on the NFS server.
Patient: Doctor, when I hit my hand to make it spin around, it hurts.
Doctor: Stop doing that, and you'll be fine. That'll be $200.
