Restarting SMTP Service on a Domino Server

Stopping and starting a Domino Server’s SMTP service

Domino Server Settings

After updating mail routing settings on a Domino Server, typically the SMTP service needs to be restarted. The best way to do this operation is from the Domino Server Console.

Domino Server SMTP start

From the Admin UI:

  1. Click the Server – Status tab and select the Server Tasks view.
  2. Click Tools – Task – Start
  3. From the list of server tasks, select SMTP Server.
  4. Click Start Task.
  5. Click Done to close the Start New Task dialog box.

From the server console:
Load SMTP

Look for diagnostic messages on the console. Allow several minutes on a busy server.

Domino Server SMTP stop

From the Admin UI:

  1. Click the Server – Status tab and select the Server Tasks view.
  2. Select SMTP Server from the list of tasks.
  3. Click Tools – Task – Stop, and then click Yes.

From the server console:
Tell SMTP quit

Look for diagnostic messages on the console. Allow several minutes on a busy server.

Domino Server SMTP restart

From the Admin UI:

  1. Click the Server – Status tab and select the Server Tasks view.
  2. Select SMTP Server from the list of tasks.
  3. Click Tools – Task – Restart, and then click Yes.

From the server console:
Restart Task SMTP

Look for diagnostic messages on the console. Allow several minutes on a busy server.

For more articles from the NewPush Managed Domino Server Team see Domino Server Support and Collaboration Services.


NFS Locking Problem on Net App connected IBM Domino Server 8.5

Problem

One of our IBM Domino servers all of a sudden decided that it couldn’t get an exclusive lock on its database files any longer. The databases happened to be on a NetApp head, and even after rebooting the server, the locking problem would persist. I other words, Domino’s nfslock was failing. As a result Domino wouldn’t start, and would send out errors to the domino startup log file similar to:

“Directory Assistance failed opening Primary Domino Directory names.nsf, error: This database is currently in use by another process”

Solution

Turns out that the NetApp lock table is sensitive to the server name and not the IP address. As a result, a lock from domino12.domain.com isn’t the same as a lock from domino12. To make matters worse, a Red Hat Linux machine might present itself either way depending on the config file details (even the order of the short name vs long name in the hosts file matters).

How to confirm the problem? On the NetApp, list the locks with

lock status -f

Now that you know the client name under witch the lock shows up, you can clear the lock with

priv set advanced
sm_mon -l clientname
priv set

Finally, you can check the the lock is gone with:

lock status -f

References