On Solaris and Linux systems, every SDK process creates a child process, sm_logerror, at startup. This process has one purpose: to print a stack trace of its parent (by invoking the pstack program) should the parent request it (which usually happens only when the parent encounters a fatal error).

Every SDK process also starts a child running an external authenticator, sm_authority (in the default configuration). This program either gets client credentials to send to a Manager, or checks credentials received by a Manager. Since the authenticator itself is an SDK program, it starts its own sm_logerror. Thus, if you follow the tree of processes under an sm_server, you might find:


Both sm_logerror and sm_authority spend their time reading a pipe that connects them to the process that created them. However, this process is not necessarily their parent. When the Manager starts as a service:

  • The Domain Manager runs as a daemon after starting sm_logerror and sm_authority.

  • The original sm_server process is replaced by a different one.

  • The child processes, sm_logerror and sm_authority, become orphans and are then inherited by the init process, which is always process 1.

    The new sm_server process retains its connection to the pipes that connected the original to the sm_logerror and sm_authority processes, and the processes work as intended

    These processes must not be "stopped". Stoping sm_logerror will make it impossible to print a stack trace, and make debugging more difficult. Stopping sm_authority will cause connection attempts to fail when credentials cannot be obtained or checked.