Seon check running daemons

From Seon
Revision as of 07:29, 15 July 2011 by Admin (talk | contribs)
Jump to: navigation, search

Which processes must run

In order to keep Seon running, the following processes must exist:

  • seonrd: The Seon master receive daemon (parent process of the subsequent receive daemon processes)
    • seonrd_tcpip: The Seon receive daemon for accepting TCP/IP connections
    • seonrd_tcpip_tls: The Seon receive daemon for accepting TLS secured TCP/IP connections for OFTP2
    • seonrd_capi_0: The Seon receive daemon for accepting ISDN connections on the first ISDN controller
    • (seonrd_capi_x: subsequent ISDN controller receivig processes, if more controllers are configured)
  • seonsqd: Seon send queue daemon. Parent process of running actions started by this process, like sending send queue entries, polling partners, updating CRLs etc.
  • seondebugd: Seon debug daemon which collects debugging information from every Seon process for problem reporting

In case you have Seon Enterprise, the following process must also exist:

  • seonclientd: Seon client daemon, responsible for user authentification and Seon Enterprise job processing

How do the processes save their state

Every Seon daemon process saves its PID (process ID) in the database. If a value exists in the database on startup, the daemon refuses to start with the message that another daemon must be running at the moment. In some rare cases, the database information may not meet the real situation, when PIDs are saved in the database and no processes are running. In this case, you can start the daemon in 'forced' mode which overrides the PID check at daemon start.

Beware: If more than one daemon is running, race conditions occur between the different running programs, mostly leading to problems in receiving or sending files. This situation is highly unsupported and absolutely to be avoided!

Identify running processes

In this example, the Seon receive daemon will be checked for existance. Furthermore, the listening functionality on the configured TCP/IP ports is being checked.

All examples are being shown in a Linux environment. If you have another supported Unix environment (like AIX, HP/UX or Solaris) you may need to modify the command accordingly.

Beware that some operating system environments may resolve port numbers to service names, so a check for open ports may lead to service names defined in a naming resolution service (such as "/etc/services", NIS or others) instead of port numbers.

normal situation

In a running envirnonment, a normal situation can be checked manually with the following command. In case of problems please refer to your operating system manual or system administrator.

checking Seon receive daemon

The process table will be checked for running "seonrd" processes:

seonbox:~# ps -ef  | grep seonrd | grep -v grep
www-data  3771     1  0 08:58 ?        00:00:00 /opt/seon/bin/seonrd
www-data  3772  3771  0 08:58 ?        00:00:00 seonrd_tcpip        
www-data  3773  3771  0 08:58 ?        00:00:00 seonrd_tcpip_tls    
www-data  3774  3771  0 08:58 ?        00:00:00 seonrd_capi_0       

Process IDs explained:

  • 3771: Seon receive daemon master process
  • 3772: daemon listening on port 3305
  • 3773: daemon listening on port 6619
  • 3774: daemon listening on first configured ISDN controller

When checking the open ports, the tool "lsof" is very handy:

seonbox:~# lsof -p 3772 | grep LISTEN
seonrd  3772 www-data    3u  IPv4 84960962             TCP *:3305 (LISTEN)
seonbox:~# lsof -p 3773 | grep LISTEN
seonrd  3773 www-data    3u  IPv4 84960964             TCP *:6619 (LISTEN)

Checking ISDN incoming call acceptance is a little bit more complicated, which is described elsewhere.

checking Seon send queue daemon

In a dormant state, only one "seonsqd" process is running:

seonbox:~# ps -ef  | grep seonsqd | grep -v grep
www-data  3823     1  2 08:59 ?        00:00:35 /opt/seon/bin/seonsqd

If running child processes are active, they may transfer files or manage Seon internal information, such as TSL management or actualizing CRLs.

checking Seon debug daemon

The Seon debug daemon must run only once, listening on the configured port for debug messages:

seonbox:~# ps -ef  | grep seondebugd | grep -v grep
www-data  4724     1  2 09:20 ?        00:00:00 /opt/seon/bin/seondebugd
seonbox:~# lsof -p 4724 | grep LISTEN
seondebug 4724 www-data    3u  IPv4 84970858             TCP localhost:10001 (LISTEN)

checking Seon client daemon

The Seon Enterprise client daemon must be running at least once. Child processes may exist, but they must have no open ports to the listening port of the configured Seon client daemon.

seonbox:~# ps -ef  | grep seonclientd | grep -v grep
www-data  4979     1  2 09:21 ?        00:00:00 /opt/seon/bin/seonclientd
seonbox:~# lsof -p 4979 | grep LISTEN
seondebug 4979 www-data    3u  IPv4 84639858             TCP localhost:60000 (LISTEN)

critical situation

A critical situation is, when PIDs are saved in the database and no corresponding Seon process exists.

In this example, the Seon administrative web interface shows that the daemons should be running with the following PIDs: PIDList.png But processes don't exist:

seonbox:~# ps -ef |grep 3772 | grep -v grep
seonbox:~# 

Since no process is running, this is a stale situation.

When to start in 'forced' mode?