Interesting Morten,

Among my utilities (downloadable here: http://community.pmail.com/files/folders/codesnippets/entry3624.aspx) you can invoke delay.exe for x-number of seconds prior to running loader.exe

Hi all

I run a small WinXp Pro SP3 as a server at home, which, among other tasks, runs Mercury/32 v4.62 with modules MercuryC, MercuryD and MercuryI enabled. I use it to fetch my mails at my ISP, and to read them from various email clients, primarily Thunderbird, Outlook Express and SquirrelMail. I do not use Pegasus. When I connect to Mercury from a client I will most of the times be rejected by Mercury because the username or password is wrong. I can retry as many times as I like, I'll be rejected every time. This happens with any number of my clients and it happens regardless of which PC runs the client. It even happens when connecting using SquirrelMail over IMAP. Enabling the logfiles on Mercury reveals that the username and password is correct. Now, if I restart Mercury all the clients can suddenly connect with no problems. This indicates that the problem must be on the serverside.

I have recently updated to v4.62 and the problem suddenly disappeared, only to come back a few days later. I'm not sure what triggers the problem, my server shuts down every night to save power, and the problem usually (but not always) happens when the first client connects. I'm completely baffled, so if anybody has some suggestions or advice please let me know.

Sup. info:

WinXp SP3 UK Professional, also runs Apache, SquirrelMail, CesarFTP, RealVNC and a music server using Windows Mediaplayer. The mails are stored on a USB stick to prevent the harddisk from spinning up every time Mercury checks for mails.

best regards

Morten Pedersen

Denmark

Enabling the logfiles on Mercury reveals that the username and password

is correct. Now, if I restart Mercury all the clients can suddenly

connect with no problems. This indicates that the problem must be on

the serverside.

Maybe, but it also may be the client.  Are you making sure that all of the IMAP4 clients have disconnected prior to shutting down the server?  If not there can be problems with IMAP4 clients and their caching. 

Are you using SSL?

I had similar problems and timeouts during authentication, which disabling SSL cured.

This happened on both Win98se & WinXP SP2 machines hosting Mercury.

You may also want to check the access to the USB stick (??!!) as the user passwords must be read from the users mail dir for authentication.

Also with all those other servers running I would have thought your disk would be spinning without Mercury checking mail. USB sticks also have a limited life when constantly being read & (esp.) written.

I would lean towards the theory that the problem has something to do with access to the Mail directory on the USB stick when the server is restarted.

I made the following quick test:

- Mercury was started with the Mail directory unavailable (in my case simply renamed). This causes no error message, but the Current user list in Mercury is empty.

- The Mail directory was then made available.

- The Current user list in Mercury was opened, and it was still empty.

So what happens is presumably this: The PMAIL.USR file in the Mail directory is read at program start and cached in memory for quick access. If the Mail directory is unavailable the list will be empty. The file will be re-read from disk only when the program is especially instructed to do so. Until that Mercury assumes that there are no local users, and login fails.

/Rolf 

Yep, that's correct - pmail.usr is cached in memory and only re-read if you issue the reload users command

Alias.mer is not cached.

Hi all

I'm not sure where to begin answering all these replies, I'm a bit overwhelmed :-) But I think the overall theory so far is that the drive on the USB stick is unavailable to Mercury. Makes sense, I guess. Furthermore, it is quite easy to test, so I tried copying the entire mail directory to c:\ . At first try it still failed miserable, but after having restarted windows (which is where the problem normally shows up) all the clients where able to login. 

Now I think I have found the root cause, mainly because of your suggestions. I start the Mercury loader from the startup folder in windows, so Mercury starts almost immediately after windows is up and running. But at that time has windows not finished enumerating the USB ports, and so the stick is not available. Seconds later has the drive appeared, so everything looks fine when I later gets a chance to look at it. Now I have created a small script that will delay the loader until the stick is ready, and some additional debug code showed that the script actually does delay the loader for a couple of loops. After a handful of reboots I have still not seen the problem. Problem solved, I hope.

Gentlemen, thanks a lot for helping, all of you who found the time to reply. It was just the information I needed. 

br

Morten