In VPOP3 version 3 and later, VPOP3 requires the PostgreSQL Database server to be accessible for it to run. If the database server is not present, or not in a suitable state, then VPOP3 will start up, but then wait for the database server to be accessible. This will make it present in task manager, and shown as running in the Services list in Windows, but it will not respond to anything.

If this is happening, then first of all, check that the VPOP3DB (or PostgreSQL-VPOP3) service is running in Windows. If this is not running, then start it.

If the PostgreSQL database service starts, then stops immediately, look in the Windows 'Application' event log to see if there are any events related to PostgreSQL.

If there is an event saying FATAL: lock file “postmaster.pid” already exists, then this means that that file exists in the VPOP3\pgsql\data folder. Usually this should be deleted when PostgreSQL closes down when the computer is shut down or restarted.

Occasionally it may not be. In that case, you can manually delete the VPOP3\pgsql\data\postmaster.pid file before restarting the VPOP3 service.

If this happens frequently, then you may wish to try the alternative method of automatically starting VPOP3.

If the PostgreSQL service is running, then the problem may be that the “VPOP3” database and user are not defined (especially if this is after a manual installation of PostgreSQL). To check this, open a command prompt and go to the PostgreSQL installation directory (usually C:\VPOP3\PGSQL) and then the bin subdirectory.

In the command prompt, type in 'pgsql -U postgres', then at the password prompt type in 'pgsqlpass'

Type in \l. This will give a list of defined databases. Check that there is a database listed called vpop3 with an owner of vpop3. If not, then the database has not been created.

To create the database/user manually type in

CREATE USER vpop3 LOGIN PASSWORD 'vpop3pass'; CREATE DATABASE vpop3 OWNER=vpop3 ENCODING 'SQL_ASCII';

then \q to exit the PostgresSQL system

One user had problems with PostgreSQL (and thus VPOP3) not starting when the PC rebooted. He found that unchecking the Enable LMHOSTS lookup setting in Windows → LAN settings → TCP/IP → WINS for his network cards fixed the problem. We are not sure why this is, but it seems to have worked for him, so it's worth trying. LMHOSTS lookup is generally not needed any more, since modern Windows networks use DNS, not WINS, so unchecking this option should have no bad effects.

Some users have problems with VPOP3 not automatically starting for various reasons, when starting it manually later will work. This can be solved by using the alternative method of automatically starting VPOP3.