System Daemon Processes

Of particular importance is the attachment of daemons (system maintenance processes which normally run permanently) to an lnode other than the root lnode. Processes attached to the root lnode are scheduled specially and will always be given all the CPU resources they demand, so it is best not to attach any process that is potentially CPU-intensive to the root lnode. Attaching daemons to their own lnode allows the central system administrator to allocate them a suitable CPU share.

During the boot procedure, each new process inherits its lnode attachment from its parent process. Since the init process is attached to the root lnode, so are all subsequent processes. Until the Solaris Resource Manager initialization script is run and the limits database is opened, processes cannot be attached to other lnodes; even then this only happens when a process does an explicit setuid system call (using login(1), for example) or explicitly asks Solaris Resource Manager to attach to a nominated lnode, like the srmuser(1SRM) command does. Running a program with the setuid file mode bit set does not change the lnode attachment.

Consequently, all system programs started automatically during system startup will be attached to the root lnode. This is often not desirable, since any process attached to the root lnode that becomes CPU intensive will severely disrupt the execution of other processes. Therefore, it is recommended that any daemon processes started as part of the boot procedure be explicitly attached to their own lnode by using the srmuser command to invoke them. This will not affect their real or effective UIDs.

A possible example is shown here:

/usr/srm/bin/srmuser network in.named 

This could be used to replace the existing invocation of the named(1M) daemon in its startup script. This requires that a user account and lnode for network be established beforehand.