FSU

Processes and Daemons

What Unix/Linux system administrators see — ps

$ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.1
DISTRIB_CODENAME=rebecca
DISTRIB_DESCRIPTION="Linux Mint 17.1 Rebecca"
$ ps -elf
F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
4 S root         1     0  0  80   0 -  8476 poll_s 10:12 ?        00:00:01 /sbin/init
1 S root         2     0  0  80   0 -     0 kthrea 10:12 ?        00:00:00 [kthreadd]
1 S langley   2559     1  0  69 -11 - 127788 poll_s 10:12 ?       00:01:06 /usr/bin/pulseaudio --start --log-target=syslog
4 S rtkit     2561     1  0  81   1 - 42228 poll_s 10:12 ?        00:00:00 /usr/lib/rtkit/rtkit-daemon
4 S root      2570     1  0  80   0 - 59838 poll_s 10:12 ?        00:00:00 /usr/lib/upower/upowerd

What Unix/Linux system administrators see -- top

[root@localhost root]# top -b -n1   # run in batch mode for one iteration
 08:17:41  up 1 day, 18:12,  2 users,  load average: 9.69, 9.14, 8.89
115 processes: 114 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    0.0%    0.0%    0.9%   0.0%     0.9%    0.0%   98.0%
Mem:   510344k av,  392504k used,  117840k free,       0k shrd,   17208k buff
                    240368k actv,   55488k in_d,    4760k in_c
Swap:  522104k av,   90392k used,  431712k free                   72852k cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME CPU COMMAND
 1090 root      20   0  1088 1088   832 R     0.9  0.2   0:00   0 top
    1 root      15   0   492  456   432 S     0.0  0.0   0:08   0 init
    3 root      15   0     0    0     0 SW    0.0  0.0   0:00   0 keventd

What Unix/Linux system administrators see - lsof

[root@localhost root]# lsof       # heavily redacted to fit on page
COMMAND    PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ssh       3075 langley    3u  IPv4  20919      0t0  TCP langley.cs.fsu.edu:48558->www.cs.fsu.edu:ssh (ESTABLISHED)
firefox   3169 langley   63u  IPv4  22194      0t0  TCP langley.cs.fsu.edu:41363->mia07s25-in-f14.1e100.net:https (ESTABLISHED)

Processes and Daemons : fork and clone

Starting a Unix/Linux process

Some Typical Assembly Code

	.file	"forty_two.c"
	.text
	.globl	main
	.align	16, 0x90
	.type	main,@function
main:                                   # @main
	.cfi_startproc
# BB#0:
	pushq	%rbp
.Ltmp2:
	.cfi_def_cfa_offset 16
.Ltmp3:
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
.Ltmp4:
	.cfi_def_cfa_register %rbp
	movl	$42, %eax
	movl	$0, -4(%rbp)
	popq	%rbp
	ret
.Ltmp5:
	.size	main, .Ltmp5-main
	.cfi_endproc


	.ident	"Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)"
	.section	".note.GNU-stack","",@progbits 
        ; this means this code does not require an executable stack

Daemon processes

When we refer to a daemon process, we are referring to a process with these characteristics:

Daemon processes

Generally a daemon provides a service. So why not put such services in the kernel?

Kernel and user daemons: init

TRADITIONAL: init (pid 1) daemon: The first ``user'' process started by the kernel; its userid is 0. All other ``normal'' processes are descendants of init. Depending on the boot parameters init, you might see something along these lines:

There is a lot of flux in this area; Redhat and Debian have both moved to systemd; hopefully, whatever the engine, we can get better dependency resolution than we have had previously and faster boot times. Gentoo (which uses OpenRC) has a nice comparison and contrast page here.

While systemd can support old AT&T scripts, it is designed to instead to have any startup parameters actually processed by systemd rather than the execution of a standalone script.

Using systemd's "systemctl" to control services.

See Redhat for more on systemd.

Treating a file system gently

Comments in the code: what Linux kernel comments say about dirty buffers and pages

/*
 * The relationship between dirty buffers and dirty pages:
 *
 * Whenever a page has any dirty buffers, the page's dirty bit is set, and
 * the page is tagged dirty in its radix tree.
 *
 * At all times, the dirtiness of the buffers represents the dirtiness of
 * subsections of the page.  If the page has buffers, the page dirty bit is
 * merely a hint about the true dirty state.
 *
 * When a page is set dirty in its entirety, all its buffers are marked dirty
 * (if the page has buffers).
 *
 * When a buffer is marked dirty, its page is dirtied, but the page's other
 * buffers are not.
 *
 * Also.  When blockdev buffers are explicitly read with bread(), they
 * individually become uptodate.  But their backing page remains not
 * uptodate - even if all of its buffers are uptodate.  A subsequent
 * block_read_full_page() against that page will discover all the uptodate
 * buffers, will set the page uptodate and will perform no I/O.
 */

(from fs/buffer.c in kernel 3.9.4)

Kernel and user daemons: inetd and xinetd

Amusingly enough, this very same line of reasoning is being revived by systemd; see this blog posting by its author. (note that daemontools also has used a related idea since 2001, but more for monitoring purposes.)

Kernel and user daemons: inetd and xinetd

Kernel and user daemons: inetd and xinetd

The configuration file structure for xinetd is /etc/xinetd.conf and also /etc/xinetd.d/*. These files are used to modify general behavior of the daemon and the directory /etc/xinetd.d contains separate files per service. Almost all distros now use xinetd instead of inetd.

Kernel and user daemons: inetd and xinetd

When installing new software packages you may have to modify /etc/inetd.conf, /etc/xinetd.d/ files, and/or /etc/services. A hangup signal (kill -HUP SOMEPID) will get the inetd/xinetd to re-read its config file. Or you might be able to use a startup script, such as ``/etc/init.d/inetd restart'') or ``service inetd restart''.

Kernel and user daemons: portmap and rpcbind

portmap/rpcbind : portmap (rpcbind on OpenSolaris and BSD) maps Sun Remote Procedure Call (RPC) services to ports (/etc/rpc). Typically, /etc/rpc looks something like:

[root@vm5 etc]# more /etc/rpc
#ident  ``@(#)rpc        1.11    95/07/14 SMI''   /* SVr4.0 
#
#       rpc
#
portmapper      100000  portmap sunrpc rpcbind
rstatd          100001  rstat rup perfmeter rstat_svc
rusersd         100002  rusers
nfs             100003  nfsprog
ypserv          100004  ypprog
mountd          100005  mount showmount
ypbind          100007
walld           100008  rwall shutdown
yppasswdd       100009  yppasswd

Kernel and user daemons: portmap/rpcbind

Kernel and user daemons: syslogd

(r)syslogd : (r)syslogd is a daemon whose function is to handle logging requests from

Note that the older syslog has generally being replaced with rsyslog.

Kernel and user daemons: syslogd

A process can make a logging request to the syslogd by using the function syslog(3). syslogd determines what to do with logging requests according to the configuration file /etc/syslog.conf

/etc/syslog.conf generally looks something like:

*.info;mail.none;news.none;authpriv.none;cron.none  /var/log/messages
authpriv.*                                          /var/log/secure
mail.*                                              /var/log/maillog
cron.*                                              /var/log/cron
*.emerg                                             *
local7.*                                            /var/log/boot.log

Kernel and user daemons: syslogd