COMPUTER AND NETWORK
SYSTEM ADMINISTRATION
CIS 5406-01
Summer 1996 - Lesson 02

Daemons
(last revision date - 5/9/96)

 XF86config file, SuperProbe
 Chapter 31: What is a daemon?

   first of all, it's daemon not demon
   demon is an evil spirit
   daemon is an attendant spirit (between human and god)
   how to see them?  LEARN YOUR LOCAL "ps" COMMAND!
   BSD-style: "ps axuw" (SunOS 4.1.x, Linux, AIX)
   SysV-style: "ps -elf" (SunOS 5.x, IRIX, AIX, HP-UX)

   daemon characteristics

     no controlling terminal
     run in background

   coding rules for starting a daemon

     make sure that the process is not a process group leader

       this can be done by forking a child and killing the parent

     create a new session

       call setsid()
       this creates a new sesssion and a new process group with no 
         controlling terminal
       if a process group leader calls setsid() an error occurs

     change the CWD to working location for the daemon
     pay attention to file mode creation mask (so any files created
       by the daemon will have the correct permissions)
     close all uneeded file descriptors (these were inherited from
       the parent)

 Why have daemons?

   modularity - don't want to have to recompile the kernel to
     modify ftpd
   kernel size - want to keep the kernel small
   robustness - don't want the kernel to crash when a lowly 
     daemon dies (say lpd)
   however, the death of the "kernel" daemons and "init" will generally 
     kill the system

 kernel and user daemons

   some daemons execute in kernel mode (pagedaemon and swapper)
   the rest execute in user mode beginning with init

 BSD swapper (PID 0)

   the swapper is a kernel daemon
   kernel memory - it functions wholly within the kernel memory
   kernel code - the code for the swapper is compiled into the kernel code
   kernel mode - it is executed in privileged execution mode 
   like a system call, the swapper does not get time quanta
   function - the swapper moves whole processes between main memory and
     secondary storage
   high page fault rate - it does this  when the system is short of 
     memory and the pagedaemon can't reclaim enough memory
   swapping out

     how does the swapper choose a process to swap out? 
     idle time - first, of the processes which have been idle for 
       more than 20
       seconds, the one with the longest sleep time is chosen
     size - second, if no resident processes have been idle for more than
       20 seconds, the daemon picks 4 largest processes
     of these 4, the one which has been  resident (not idle) 
       the longest amount of time is chosen

   swapping in

     runnable - when a process becomes  runnable it is swapped in
     if more than one process is ready to be swapped in, a choice
       is made
     oldest swapped - in general, the process that has been swapped 
       out the longest gets in first

   SA RELEVANCE:

     the swapper is the first process to start after the kernel
       is loaded
     if the machine crashes immediately after the kernel is loaded
       then you may not have your swap space configured correctly
     was the kernel configured correctly?
     "mkfile" - if the swap space is on a UFS or NFS partition use
       mkfile which does a zero fill and sets sticky bit

   OS other than BSD

     the swapper is described as a separate kernel process by Bach
     It does not appear in the Linux process table
     It does appear on AIX, HP-UX, IRIX, for example
     it appears in the Solaris process table as  sched
       (the SysV swapper is sometimes called the scheduler because
        it 'schedules' the allocation of memory and thus influences
        the CPU scheduler)

 BSD pagedaemon (PID 2)

   the second process created by the kernel is the pagedaemon
   the pagedaemon is a kernel process
   originated with BSD systems (demand paging is a BSD feature) which was
     adopted by AT&T during System V
   I am assuming that the  pageout process (PID 2) in Solaris
     implements  pagedaemon's work
   the pagedaemon sleeps until awakened by the kernel
   the kernel checks 4 times per second to see if the
     system needs memory
   if so, the kernel awakens the pagedaemon
   the pagedaemon then:

     uses a two-handed clock algorithm ("enhanced second chance")
     chooses pages for replacement
     if page is 'clean' then page is freed
     if page is 'dirty' then writes out modified page to disk
     it does this asynchronously so that the algorithm can
       continue and not block for disk I/O
     a page is freed by adding it to the memory free list

   SA RELEVANCE:

     this is all automatic - not much for the SA to do
     we will talk about VM management in the section on 
       performance tuning

 init (PID 1)

   the first user process
   all other processes are children of init
   depending on the boot parameters init either:

     spawns a single-user shell at the console
     begins the multi-user start-up 
     we'll talk more about this when we discuss Booting the
       System

 update()

   executes sync() every 30 seconds
   what does sync() do?
   flushes buffer cache - sync schedules the disk I/O
   delayed write - it is needed because UNIX uses delayed write for 
     its buffer cache
   SA RELEVANCE:

     don't let users re-boot your UNIX systems
     it is better to halt the system using /etc/shutdown or halt
     these commands attempt to put the system in a quiescent state
       before calling sync()

   other OS

     see  bdflush and update in Linux
     see  fsflush in Solaris (PID 3)

 inetd

   even though well-written daemons consume little CPU time
     they do take up process table slots
   there began to be so many daemons that a super-daemon
     was written to manage the class of network daemons 
   many network servers are mediated by the  inetd daemon
   they may also be run without the inetd - started at boot time
     and run forever
   inetd listens for requests for connections and then starts the
     appropriate daemon
   some examples are: rlogin, telnet, ftp, talk, finger
   the inet daemon forks a child to handle the request
   the child inetd execs a server (for example, telnetd)
   the configuration file that tells the inetd which servers to
     manage is /etc/inetd.conf
   /etc/services

     but before looking at inetd.conf lets look at /etc/services
     this file maps TCP and UDP protocol server names to port numbers
     view /etc/services file
     note that some services support both tcp and udp protocols
     you can type: 'telnet xi.cs.fsu.edu smtp' to connect to
       the sendmail port

   Sun RPC services are mapped to ports by the portmapper daemon
   look at inetd.conf

     the 1st column is the name of the service
     the 2nd column designates the type of socket to
       be used with the service (almost always stream or datagram)
     the 3rd column designates the communication protocol (tcp
       is almost always paired with stream sockets and udp is almost
       always paired with datagram sockets)
     the 4th column applies only to datagram sockets - if the daemon can
       process multiple requests then put 'wait' here so the inetd
       doesn't keeping forking new daemons - this only applies to
       datagram sockets
     the 5th column specifies the username that the daemon should run
       under (for example - let's have fingerd run as 'nobody' until
       we can find the security hole)
     the remaining columns give the pathname and arguments of the
       daemons

   SA RELEVANCE:

     when installing new software packages you may have to modify
       inetd.conf and/or /etc/services (see GNU finger)
     a hangup signal will get the inetd to re-read its
       config file - 'kill -SIGHUP pid' 
     internet daemons (particularly sendmail) have been the source
       of security holes
     two methods of adding security are a tcpwrapper and a different
       inet daemon
     Linux (usually) comes with the "tcpd" wrapper installed

 portmap

   as mentioned above, maps RPC services to ports (/etc/rpc)
   RPC servers register with this daemon
   RPC clients get the port number for a service from the
     daemon
   you can get a lot of information using 'rpcinfo'
   for example, rpcinfo -p will list the RPC services on
     the local machine
   then you can see which other machines on the same local
     network provide the same services
   try: rpcinfo -b ypbind 1

 syslogd

   the syslogd is a daemon whose function is to handle logging
       requests from:

     the kernel
     other user processes (daemons)
     processes on other machines (across the net)

   a process can make a logging request to the syslogd by using
     the function syslog()
   syslog(priority, message, facility)
    priority is level of criticality such as LOG_ALERT or 
     LOG_WARNING
    message is a string containing the message to be sent
    facility - source of message: LOG_USER, LOG_KERN,
     LOG_MAIL 
   the syslogd determines what to do with logging requests according
     to the configuration file /etc/syslog.conf

   a look at syslog.conf

     example from syslog.conf
    
    *.err;kern.debug;user.none            /dev/console
    *.err;kern.debug;daemon,auth.notice;  /var/adm/messages
    auth.notice   ifdef(`LOGHOST', /var/log/authlog, @loghost)

     line 1 says write messages of priority level LOG_ERROR from all
       sources to /dev/console (also kernel debug and no user messages)
     line 3 ships authorization messages to the LOGHOST (nu)
     if you want to log a message you can make the call:
 
       syslog(LOG_ERR,''hi there, etc, etc'',LOG_USER);