COMPUTER AND NETWORK
SYSTEM ADINISTRATION
CIS 5406-01
Summer 1999 - Lesson 2
Daemons and Services
UNIX
First of all, it's daemon not demon
o demon is an evil spirit
o 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)
See page 278 of ESA.
Daemon characteristics
no controlling terminal
runs in background
Note that these general characteristics are similiar to a Windows NT
service.
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 some "kernel" daemons 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 (swapping out and swapping in)
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? (See page 316 in ESA).
OS other than BSD
the swapper is described as a separate kernel process by Bach
It appears in the Linux process table as kswapd.
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 was initially a BSD feature) which was
adopted by AT&T during System V
Pageout process (PID 2) in Solaris
implements pagedaemon's work
SA RELEVANCE:
this is all automatic - not much for the SA to do, except
monitor system behavior to make sure the system isn't thrashing.
init (PID 1)
the first user process (user == root)
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 scripts
update()
executes sync() every 30 seconds
what does sync()system call 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 (via physical access)
It is better to halt the system using /etc/shutdown or halt
these commands attempt to put the system in a quiescent state
including 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
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 (Remote Procedure Call) 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
the 5th column specifies the username that the daemon should run
under (for example - let's have fingerd run as 'nobody')
the remaining columns give the pathname and arguments of the
daemons (here's where TCP wrappers are typically installed).
Linux (usually) comes with the "tcpd" wrapper installed
SA RELEVANCE
when installing new software packages you may have to modify
/etc/inetd.conf and/or /etc/services
a hangup signal will get the inetd to re-read its
config file - 'kill -HUP pid'
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_AIL
the syslogd determines what to do with logging requests according
to the configuration file /etc/syslog.conf
Example 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 sends authorization messages to the LOGHOST
If you want to log a message you can make the call:
syslog(LOG_ERR,''hi there, etc, etc'',LOG_USER);
Windows NT
You can see the processes running under Windows NT 4.0 via the
Windows NT Task Manager -- Press CTRL-ALT-DEL, select
Task Manager, or just press CTRL-SHIFT-ESC.
You can see/end/modify/switch/create applications,
see/end processes, and view CPU/memory performance.
A nice feature of the Processes display is the
ability to sort on any column by clicking on the
column header (the sort toggles from ascending/descending).
Quite a nice display!
You can also view the lists of services through the Control
panel "Services" icon.
Page 48 of EWNTSA gives more information on managing NT services, like
the slick "sclist" command (from the NT Resource Kit; more on this later).
We will cover NT's logging of system errors and events later.