Vector Processes on Linux
The major Vector processes are as follows:
• X100 process (iix100)
• Name Server process (iigcn)
• Communications Server process (iigcc)
• Recovery process (II_IUSV_nnn)
• Archiver process (dmfacp)
• DBMS Server process (iidbms)
• Data Access Server process (iigcd)
• Bridge Server process (iigcb)
• Remote Command process (rmcmd)
Name Server Errors on Linux
The Name Server process (iigcn) is not running if either of the following occurs:
• You receive a specific error indicating that the Name Server process (iigcn) failed to start.
• The command ps -aux (BSD) or ps -ef (System V) shows that the iigcn is not running.
You can verify this by attempting to start the Name Server manually.
Check for Name Server Errors on Linux
If the Name Server does not start, follow these steps:
1. Verify that TCP/IP is properly installed by typing the following command at the operating system prompt:
telnet localhost
A loopback login to your machine occurs.
2. Verify that the required TCP daemon process for your operating system is running.
The specific process name is system dependent, but on many Linux systems, the process is named “inetd” (use your process name in the command below if it is not inetd). Issue the following command at the operating system prompt, or see your operating system manual for your particular TCP/IP implementation:
BSD:
ps -aux | grep inetd
System V:
ps -ef | grep inetd
3. Check that the Vector environment variable II_GCNxx_PORT is not set (this environment variable contains the TCP port identifier of the Name Server process):
a. Use the ingprenv utility to verify that this environment variable is not set when the Name Server tries to start up.
b. If necessary, use the ingunset command to unset the II_GCNxx_PORT environment variable.
4. If you corrected a Name Server problem, verify that Vector starts normally:
a. Shut down the partially started installation with the ingstop command.
b. Restart the installation with the ingstart command.
5. If you are still having problems, set the following trace to capture additional diagnostic data before calling technical support:
Bourne Shell:
II_GC_TRACE=5
II_GC_LOG = stdio (stdio or filename); export II_GC_TRACE II_GC_LOG
C Shell:
setenv II_GC_TRACE 5
setenv II_GC_LOG stdio (stdio or filename)
iirun iigcn
Check for Communications Server Process Errors on Linux
If the Communications Server process (iigcc) did not start, follow this procedure:
1. Verify that no local environment variables are set in the local user environment that contain the string “GCC”. At the operating system prompt type the command:
BSD:
printent | grep GCC
System V:
env | grep GCC
The Vector environment variable II_GCNxx_PORT is set in the Vector symbol table. It is not visible from the Linux environment using the printenv or env commands, but is visible in the Vector environment. Verify this by typing ingprenv.
2. Check the value of the Vector environment variable II_RUN with the following command entered at the operating system prompt:
ingprenv
a. If this machine is running Ingres Net, the value of II_RUN is either “,NET” or “,DBMS, NET”. If the value of the Vector environment variable II_CLIENT is TRUE, II_RUN is “,NET”. If II_RUN is not set correctly, reset it using the command:
ingsetenv II_RUN ', DBMS, NET'
b. If this machine is an NFS client (that is, does not run a DBMS Server locally) the value of II_RUN is “,NET”. If II_RUN is not set correctly, reset it using the following command entered at the operating system prompt:
ingsetenv II_RUN', NET'
For details on setting environment variables, see the chapter "Setting Environment Variables."
3. If you are still having problems, set the following trace to capture diagnostic data and attempt to restart the Communications Server:
Bourne Shell:
II_GCC_TRACE=4
II_GCA_LOG=stdio
export II_GCC_TRACE II_GCA_LOG
iirun iigcc
C Shell:
setenv II_GCC_TRACE 4
setenv II_GCA_LOG stdio
iirun iigcc
4. If you corrected a Communications Server problem, verify that Vector starts normally:
a. Shut down the partially started installation with the ingstop command.
b. Restart the installation with the ingstart command.
Check for Bridge Server Process Errors on Linux
If the Bridge Server process (iigcb) did not start, verify that you have installed the Ingres Net component and that you have installed the correct protocol drivers.
If you are still having problems, set the following trace to capture additional diagnostic data before calling technical support:
ingsetenv II_GC_TRACE 4
ingsetenv II_GC_LOG filename
ingstart -iigcb
Recovery Process Errors on Linux
The recovery process (dmfrcp) must be running before a DBMS server can be started. Failure of the dmfrcp starting process indicates one of the following:
• Problems with the log file
• Insufficient or previously allocated shared memory
Check for Recovery Process Errors on Linux
If the recovery process does not start, perform the following procedure:
1. Check that the shared memory resources are properly installed. Use the csreport utility and check that the size, ownership, and permissions of the semaphore and shared memory segments meet the minimum requirements for your port.
2. Check for the existence of the transaction log by opening the Primary Transaction Log window in Configuration Manager (or the Transaction Log screen in the Configuration-By-Forms (cbf) utility), and noting the directories listed in the Log File Root Locations table in Configuration Manager (or the Primary Transaction Log Locations table in cbf).
3. Look for the file ingres_log.lnn (where nn is an integer between 1 and 16) in the ingres/log directory (located below all other listed directories).
4. Make the following checks on the transaction log file ingres_log.lnn:
a. Verify that ingres_log.lnn exists at that location by entering the following command at the operating system prompt:
ls -l
If it does not exist, you must recreate it using the Configuration-By-Forms (cbf) or Configuration Manager (vcbf) utility.
b. Verify that ingres_log.lnn is owned by installation owner.
If it is not, issue the following command at the operating system prompt, where userid is the user ID of the installation owner:
chown userid ingres_log
c. If the transaction log file was created as:
An ordinary Linux file, make sure it has permissions 660 (that is,
“-rw-rw----”). If not, issue the following command at the operating system prompt:
chmod 660 ingres_log
A raw log, permissions is “crw------”.
5. Verify that Vector starts normally.
a. Shut down the partially started installation with the ingstop command.
b. Restart the installation with the ingstart command.
6. If you still cannot start the II_IUSV_nnn process, you need to completely shut down the installation, re-run ingbuild, and reconfigure the log file.
IMPORTANT! This step must only be done as a last resort. Keep in mind that this reinitializes the log file, and any outstanding transactions are lost.
To shut down the system, complete the following steps:
a. Issue the command ingstop.
Check for Remote Command Process on Linux
You can check for the presence of the optional remote command process by entering the following command at the operating system prompt:
ps -ef | grep rmcmd
Archiver Process on Linux
The archiver process (dmfacp) does not start unless the recovery (dmfrcp) process is running
. However, an installation runs without an archiver process until the log file fills up. User programs are suspended as outstanding transactions in the log file are backed out
. For information about the
Vector recovery state, see
Recovery Process Monitoring.
• Archiver process (dmfacp) startup errors are likely to result from:
• Improper shared memory resources
• Inability to read the transaction log file
• Inability to write journal files
Check for Archiver Process Errors on Linux
Use the following procedure to check archiver process startup problems. Some of these checks are the same as for the recovery process:
1. Check that the shared memory resources are properly installed: Use the csreport utility and check that the size, ownership and permissions of the semaphore and shared memory segments meet the minimum requirements for your port. For requirements, see the Readme file.
The command to allocate Vector shared memory and semaphores (when logged is as the installation owner) is csinstall. You can display them from Linux with the command ipcs.
2. Make the following checks on the transaction log file “ingres_log”:
a. Verify that “ingres_log” exists at that location by entering the following command at the operating system prompt:
ls -l
If it does not exist, you must create it by running the ingbuild program.
b. Verify that “ingres_log” is owned by the user that owns the installation.
If not, issue the following command at the operating system prompt, where userid is the user who owns the installation:
chown userid ingres_log
c. If the transaction log file was created as:
An ordinary Linux file, make sure it has permissions 660 (that is,
“-rw-rw----”). If not, issue the following command at the operating system prompt:
chmod 660 ingres_log
A raw log, permissions is “crw------”.
Check that the II_JOURNAL location is a valid location. Issue the following command at the operating system prompt:
infodb | grep ii_journal
3. Check journal locations by verifying that:
a. The journal location name points to a valid directory containing subdirectories “ingres/jnl/default/dbname”
b. The permissions on these directories are:
- 755 for the ingres directory
- 777 for the default directory
4. Check that the disk partition containing the journal files is not 100% full. Issue the following command at the operating system prompt:
df
If a journal partition is 100% full, it is impossible to write journals and the Archiver stalls. If this is the reason preventing Archiver startup, you must either free space on the journal partition or temporarily disable journaling with the alterdb command.
5. If you corrected an Archiver process problem, verify that Vector starts normally:
a. Shut down the partially started installation with the ingstop command.
b. Restart the installation with the ingstart command.
Check for DBMS Server Process Errors on Linux
The command to start the DBMS Server process (iidbms) from the installation owner login is ingstart -iidbms. If the DBMS Server did not start:
2. Verify that the recovery process is not in a
recovery state. (See Recovery Process Monitoring.) This is likely if there was a sudden shutdown because of a power failure or other system failure.
3. Try to start up a DBMS server. Issue the following command at the operating system prompt:
ingstart -iidbms
4. If you corrected a DBMS server problem, verify that Vector starts normally. Shut down the partially started installation with the ingstop command.
5. Restart the installation with the ingstart command.
Check for Data Access Server Process on Linux
The command to start the Data Access Server process (iigcd) from the installation owner login is ingstart -iigcd. If the Data Access Server did not start:
2. Verify that the
recovery process not in a recovery state. (See
Recovery Process Monitoring.) This is likely if there was a sudden shutdown because of a power failure or other systems failure.
3. Try to start up a Data Access server. Issue the following command at the operating system prompt:
ingstart -iigcd
4. If you corrected a Data Access server problem, verify that Vector starts normally:
a. Shut down the partially started installation with the ingstop command.
b. Restart the installation with the ingstart command.