Subject: RE: wuftpd file locks

From: "Roger A. Hanke" <[email-masked]>
Date: Mon, 3 Nov 1997 12:10:32 -0500

Chris,
 Wanted to ask a couple more questions on this file locking issue since
I am now running enough of a load that the fcntl syslog error is being 
seen routinely.

 Reading into your response below it almost sounds like the fcntl being
done is a write lock just because the pid file needs to be written. But all
other files only require a read lock as far as I know. Wouldnt just putting
a write lock on the pid file, and using read locks on any other configuration
files being read, minimize this contention window at least?

 Did you ever come up with a better approach for this whole process?
	Thanx,
	Roger Hanke  

----------
From: 	Chris Brown[SMTP:[email-masked]]
Sent: 	Thursday, May 01, 1997 6:17 PM
To: 	Roger A. Hanke
Subject: 	Re: wuftpd falling over

> 
> Chris,
>  A little confused by this. Since WUFTPD startup only requires read
> access to its configuration files, why would it be locking them?

It does lock them since it also needs to read/write the .pid files in a safe
way.

> And even more concerned after seeing Alain's response. What is the max 
> number you have been able to support, hopefully more than a 100?

This _really_ depends.  If your ftp server is serving up many small files to
MSIE users, 100 is about max.  On my server, people download large files (1+
megs) so I can support more.  Even so, there is a limit, and it's not
terribly large.

Chris...

> ----------
> From:  Chris Brown[SMTP:[email-masked]]
> Sent:  Tuesday, April 29, 1997 1:04 PM
> To:  [email-masked]
> Subject:  Re: wuftpd falling over
> 
> > I have heard rumours that wu-ftpd falls over when you have about 3000
> > people using it. Is this true. If so what can I use.
> > 
> > Or can I fix it
> 
> This is probably true 'cause wuftpd depends on locking a file in order to
> get its access information.  With thousands of users I would expect wuftpd
> to effectively deadlock.  I had been putting some work into a more reliable
> method of doing this but I'm not on the developement team so anything I do
> isn't likely to be incorperated into any release.
> 
> Chris...
> 
>