582 Chapter 25 using Gigabit Ethernet (GigE) whenever possible will improve Internet server/ service performance Finally, using a higher-performance filesystem on the directories that hold email can substantially improve performance For example, ext3 does a great job on mail partitions because short-lived mail files might not even need to be created in the filesystem if they pass through the filesystem journal quickly enough ReiserFS can be a good idea for mail partitions on which hundreds of thousands of tiny files live in the same directories Optimizing LDAP Services Several items in the slapd configuration can be tweaked to give better server performance The items shown in the following list show configuration directives that can be modified for performance reasons: ■■ Cache size modification — You can increase the size of the cache using the cachesize directive in slapd.conf For example, the following directive sets the number of LDAP entries stored in the cache to 100,000: cachesize 100000 ■■ Disk subsystem — As suggested elsewhere in this chapter, replace IDE disks with SCSI disks, and replace or augment SCSI disks with FibreChannel If SCSI and FibreChannel are too rich for your budget, using Serial ATA (SATA) drives (and a SATA controller, of course) hits a good middle ground because SATA is faster than IDE and less expensive than SCSI and FibreChannel If you have multiple LDAP data stores, situate each store on its own disk and, if possible, its own dedicated I/O controller in order to minimize I/O contention with other processes ■■ Filesystem tuning — On filesystems that support it, disable updating file access and modification timestamps, which will decrease the number of file operations that have to be performed by two-thirds Fewer CPU cycles spent on bookkeeping means more CPU cycles spent doing actual LDAP-related work ■■ Indexing — With limits, indexes increase performance, but at the cost of additional memory, disk, and CPU usage Accordingly, don’t index data you don’t (often) search By way of guidelines, index only heavily used parts of your schema ■■ Logging — If you are persuaded that excessive message logging is hampering the performance of your LDAP server, add the following entry to slapd.conf: loglevel This entry disables logging via the system log Optimizing Internet Services ■ ■ System memory — In addition to adding more physical memory, increase the size of OpenLDAP’s cache to use more RAM For more details about these performance tuning tips, have a look at the OpenLDAP FAQ, available on the Web at openldap.org/faq/data /cache/190.html Optimizing DNS Services Optimizing DNS services centers on reducing the latency involved in making DNS queries For client programs, that is, for applications requesting DNS services, the best all around performance enhancement is to maintain a local cache of DNS information You get the most bang for your performance buck by reducing the number of DNS queries that have to go to a remote server, even if that server is inside the subnet to which you are connected The typical approach is to run a caching-only name server on client machines On the server side, you have a much wider range of options, as discussed in the section titled “Tweaking DNS Servers,” later in this chapter Improving the Performance of DNS Clients To increase the performance (and security) of your caching-only servers on the DNS clients, several options can be modified in the /etc/named.conf file created during the installation of BIND The /etc/named.conf file is shown in Listing 25-1 // generated by named-bootconf.pl options { directory “/var/named”; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default */ // query-source address * port 53; }; // // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; Listing 25-1 The /etc/named.conf file (continued) 583 584 Chapter 25 }; zone “.” { type hint; file “named.ca”; }; zone “localhost” { type master; file “localhost.zone”; allow-update { none; }; }; zone “0.0.127.in-addr.arpa” { type master; file “named.local”; allow-update { none; }; }; include “/etc/rndc.key”; Listing 25-1 (continued) The section of the file in which you are interested is the options section Since this is a caching-only server, you can safely disable functions that are not necessary for this type of server You can also add options that apply to a caching-only server By default, BIND allows zone transfers to all hosts However, zone transfers are necessary only for master and slave servers; they aren’t necessary for DNS clients You can disable zone transfers by adding the following line to /etc/named.conf: allow-transfer { none; }; You can also configure you caching-only server to respond to regular queries only from specific hosts BIND’s default setting is to allow queries from any host Typically, you want to allow queries only from hosts inside your firewall You can add the following line to the options section in /etc/named.conf, replacing www.xxx.yyy.zzz with your network IP number: allow-query { www.xxx.yyy.zzz; localhost; }; You can also configure your caching-only server to respond to recursive queries from only specific hosts BIND’s default setting is to allow queries Optimizing Internet Services from any host Typically, you want to allow queries only from hosts inside of your firewall You can add the following line to the options section of /etc/named.conf, again replacing www.xxx.yyy.zzz with your network IP number: allow-recursion { www.xxx.yyy.zzz; localhost; }; Typically, a caching-only server does not have direct access to the Internet, so it creates a cache file to hold dns information This is the purpose of a caching-only server, and it boosts performance by eliminating the need to send queries to external servers But if the server does not have the information it needs in its local cache, it needs to send a request to other servers You can specify the IP address of the servers to which you want to forward requests Add the following line to the options section of /etc/named.conf, replacing www.xxx.yyy.zzz with the IP address of the name server to which requests should be forwarded: forwarders { www.xxx.yyy.zzz; }; What happens if the servers you are forwarding to are down? Your server tries to forward the request to other servers You can prevent this from happening by adding this line: forward only; Tweaking DNS Servers To increase the performance and security of your master domain server on the DNS clients, several options can be modified in the /etc/named.conf file created during the installation of BIND Make changes to the options section of /etc/named.conf By default, BIND allows zone transfers to all hosts Zone transfers are necessary only between the master and slave servers, so you can specify the IP address of your slave server by adding the following entry (replace www xxx.yyy.zzz with the IP address of your slave server): allow-transfer { www.xxx.yyy.zzz; }; 585 586 Chapter 25 You can also configure your master server to respond to regular queries only from specific hosts The default setting in BIND is to allow queries from any host Typically, you want to allow other types of queries only from hosts inside your firewall You can add the following line to the options section: allow-query { www.xxx.yyy.zzz; localhost; }; Replace www.xxx.yyy.zzz with your internal network IP number You can also configure your caching-only server to respond to recursive queries only from specific hosts The default setting in BIND is to allow queries from any host Typically, you want to allow queries only from hosts inside of your firewall You can add the following line to the options section: allow-recursion { www.xxx.yyy.zzz; localhost; }; Again, replace www.xxx.yyy.zzz with your internal network IP number Logging You can configure your caching-only slave and master servers to automatically rotate your /var/log/named.log file to prevent your filesystem from filling up with old information The file /etc/logrotate.d/named should have been created during the installation of BIND and should be similar to Listing 25-2 /var/log/named.log { missingok create 0644 named named postrotate /sbin/service named reload endscript } 2> /dev/null || true Listing 25-2 The /etc/logrotate.d/named file controls log rotation of BIND’s log files If you not have /etc/logrotate.d/named on your system, create it by copying the file as shown in the listing Then make the following changes Remove this line: create 0644 named named Optimizing Internet Services Change the line: /sbin/service named reload 2> /dev/null || true to: /bin/kill -HUP `cat /var/run/named.pid 2> /dev/null` 2> /dev/null || true Be sure to save your changes and restart the named server Another tweak you can make is to disable logging for LAME servers These are servers that appear to be name servers for a domain but are not This reduces system-resource use Add the following line to your /etc/named conf file: logging { category lame-servers { null; }; }; Optimizing Mail Services To improve the speed of your mail services, you can take one of several approaches Busy sites often use multiple mail servers in order to spread the mail processing load across a number of systems This reduces the demand on any single system Another common performance enhancement is to replace Sendmail with another mail server, such as Postfix If your mail server supports a number of mailing lists, you might consider handling list traffic on one server and regular (nonlist) mail traffic on another server If you are not in a position to buy a beefier mail server, to buy more mail servers, or to replace Sendmail with Postfix, the section titled “Getting More from Sendmail,” later in this chapter, offers a number of tips and hints to help you squeeze more speed out of it “Getting More from Postfix,” also later in this chapter, gives you a number of methods you can try to get better performance from Postfix Getting More from Sendmail The /etc/mail/sendmail.cf file contains many options that can be tweaked to give better performance and increase the efficiency of your mail server The most common Sendmail tweak if to change the frequency with which it runs the queue You can modify this by editing /etc/sysconfig/sendmail and changing the line that reads QUEUE=1h, which causes Sendmail to process the mail queue every hour, to, for example, QUEUE=15m, which runs the queue every 587 588 Chapter 25 15 minutes If you modify this file, you have to restart Sendmail A good source for some performance-tuning tips can be found at the Sendmail Web site at sendmail.org/~ca/email/doc8.12/TUNING Getting More from Postfix If you have a lot of mail that just seems to sit in Postfix’s outbound queue, you may be trying to deliver mail to a site that is quite busy One way to work around this problem is to create a transport map entry for such a site that enables multiple parallel connections and then to give each connection to that site a shorter timeout Suppose, for example, that you know that slowsite.com and reallyslowsite.net are busy sites, and you have trouble getting email to them in a timely manner First, create entries resembling the following in /etc/postfix/transport: slowsite.com reallyslowsite.net deadbeats: deadbeats: These entries in /etc/postfix/transport add slowsite.com and reallyslowsite.net to an alias named deadbeats Next, create a corresponding entry in /etc/postfix/main.cf that increases the number of simultaneous connections to 50, which allows more mail to slowsite.com and reallyslowsite.net to be transmitted at once transport_maps = hash:/etc/postfix/transport deadbeats_destination_concurrency_limit = 50 The key directive here is deadbeats_destination_concurrency_limit = 50, which increases the number of parallel connections to slowsite.com and reallyslowsite.net to 50 deadbeats unix n smtp -o smtp_connect_timeout=5 -o smtp_helo_timeout=5 These entries from /etc/postfix/master.cf tell Postfix that SMTP connections to sites in the deadbeats alias should timeout after seconds and that, similarly, an SMTP transaction must commence within seconds of the HELO command, or the connection will be closed If incoming mail seems to queue up while outbound mail gets delivered, then outgoing mail is crowding out incoming mail Postfix can waste a great deal of time waiting for connections to time out, so, again, the solution is to reduce the connection timeout for incoming email, modifying /etc/postfix /master.cf as follows: Optimizing Internet Services relay unix n smtp -o smtp_connect_timeout=2 -o smtp_helo_timeout=2 If you see that Postfix pegs disk I/O when processing incoming mail, the real solution is to get faster disks or to allocate one disk for logging, one disk for the mail queue, and a third disk for user mailboxes Postfix-caused disk saturation is especially a problem if you are serving multiple virtual hosts on a single system One workaround is to configure multiple IP addresses for the machine and to run a Postfix instance for each IP address, where each Postfix instance writes to a different disk It is easier to configure than it might seem at first glance The key is starting each Postfix instance with a different configuration directory: # postfix -c conf_dir start Replace conf_dir with the name of the configuration directory assigned to each IP address Within each conf_dir, main.cf has a different $myhostname, $queue_directory, and $inet_interfaces setting, depending on the interface or IP it handles For example, if you have two virtual hosts, first.vhost.com and second.vhost.com, you might arrange it like this: For first.vhost.com, suppose that the Postfix’s configuration directory is /first/postfix Thus, the configuration file /first/postfix /main.cf might have the following entries: queue_directory = /first/queue/dir myhostname = first.vhost.com inet_interfaces = $myhostname Accordingly, start the Postfix instance for first.vhost.com this way: postfix -c /first/postfix start Make a similar arrangement for second.vhost.com If the configuration directory is /second/postfix, the configuration file is /second/postfix /main.cf, which has the following entries for second.vhost.com: queue_directory = /second/queue/dir myhostname = second.vhost.com inet_interfaces = $myhostname The proper Postfix invocation is: postfix -c /second/postfix start 589 590 Chapter 25 If Postfix responds too slowly to incoming SMTP connections but POP or IMAP connections are acceptably fast, you need to run more SMTP server processes Edit the smtpd entry in the master.cf file and increase the process limit Alternatively, increase the default_process_limit setting in the main.cf file T I P Anytime you edit one of Postfix’s configuration files, be sure to use the postfix reload command to activate the changes Optimizing FTP Services Out of the box, vsftpd is pretty darn fast and makes lightweight demands on a system’s memory and CPU resources If its speed fails to suit you, the following tips, adapted from the vsftpd documentation, might help: ■■ If possible, disable the NIS and NIS+ (nis and nisplus) for passwd, shadow, and group lookups in /etc/nsswitch.conf The idea with this tip is to avoid loading unnecessary runtime libraries into the vsftpd’s memory space and to avoid using NIS for lookups that can be resolved more quickly by resorting to file-based lookups ■■ Break directories with more than a few hundred entries into smaller directories Many file systems, such as ext2 and ext3, not handle such cases efficiently at all, and the process of creating listings of large directories (with, for example, the ls or dir commands) causes vsftpd to use moderate amounts of memory and CPU If you are stuck with large directories, use a file system, such as XFS, JFS, or ReiserFS, designed to work with large directory structures ■■ Limit the number of simultaneous connections to the FTP server ■■ More drastically, if the load on your FTP server is bogging down the system, you could disable anonymous FTP altogether or dedicate a machine to providing FTP services ■■ Take advantage of vsftpd’s bandwidth throttling features to limit the network bandwidth consumed by any one connection or connection classes Optimizing Web Services Chapter 23 briefly touched on Apache configuration settings you can modify that affect Apache’s performance The settings mentioned in that section are Optimizing Internet Services good starting points for fine-tuning Apache, but they not exhaust the possibilities To recap that discussion: ■ ■ Increasing the MaxClients setting (to a maximum of 256) increases the maximum number of simultaneous client connections to the httpd server before the server starts refusing additional connections The default value is 150 (clients) One generally-accepted rule-of-thumb formula is: MaxClients = Physical RAM – 128 MB + Size of Active Pages Nonshared Memory per httpd Process The theory is that you should use physical RAM for system resources and caching active pages Leftover RAM should be used by httpd processes serving up active pages If you have more clients, you will end up swapping, which degrades performance If you have fewer clients, you will not be maximizing the available system resources In practice, you will have to decide what constitutes an active page One way to go about this is to use the server logs to evaluate which pages are served more than once every TimeOut period, which defaults to 300 seconds (5 minutes) ■ ■ The TimeOut directive controls how long the server waits between protocol messages before it closes a connection The longer the TimeOut directive, the longer a client connection will be tied up and, thus, unavailable to another client The default value is 300 (seconds) ■ ■ The MaxRequestsPerChild setting controls how many HTTP requests an httpd child process will service before a new child process starts The default value is 100, but setting it to 0, for unlimited requests, will work just fine on a Red Hat system ■ ■ MaxKeepAliveRequests, 100 by default, sets the upper limit on the total number of requests from the same client on the same connection The following tips and suggestions appear in no particular order Your mileage may vary, and if breaks, you get to keep both pieces Some of the following might work better than others; others ideas might fail miserably If your server is running a lot of CGI scripts or using PHP markup, you should look into resources that discuss Apache tuning in depth The overhead requirements of PHP and CGI scripts involve creating new processes rather than merely additional RAM, network, or disk I/O ■ ■ Set HostnameLookups to Off Each resolver call impairs performance If you need to resolve IP addresses to hostnames, you can use Apache’s logresolve program or one of the resolver programs available in the log reporting and analysis packages 591 670 Chapter 27 The initrd image contains drivers that the kernel needs to boot and that are neither compiled statically into the kernel nor otherwise accessible at boot time The classic example of this is drivers for the disk on which the root file system is stored If the kernel doesn’t contain a built-in driver for the disk that contains the root file system, it can’t mount the root file system; if the kernel can’t mount the root file system, it can’t load the driver Storing the driver in an initrd that the kernel loads at boot time avoids this catch-22 After you’ve installed the kernel, modules, and created an initrd, you can update the boot loader configuration file Updating GRUB To make GRUB aware of the new kernel, open /boot/grub/grub.conf in the text editor of your choice and add a stanza at the bottom that resembles the following: title Kurt’s Kustom Kernel (2.6.11.7) root (hd0,0) kernel /vmlinuz-2.6.11.7-custom ro root=/dev/hda3 initrd /initrd-2.6.11.7.img The title line is the name that appears in GRUB’s menu when your system first boots The root line tells GRUB the device (hd0) and partition (0) to mount The kernel line tells GRUB where to find the kernel image and the command line parameters to pass to the kernel as it boots (ro root=/dev/hda3) The initrd line, finally, tells GRUB where to find the initrd image Because the system used for this example has a separate /boot partition, the paths to the kernel and initrd image are defined relative to the /boot partition If you are unsure how to modify the example stanza for your system, the easiest thing to is copy an entry for one of the existing kernels and modify it with values appropriate for you system To configure GRUB to boot the new kernel by default, change the value of the default directive to correspond to number of the title section that contains the new kernel The count starts with For example, if your new kernel is the fifth title section, change the line that reads default=0 to default=4 (remember, the count is zero-based) However, before you make the new kernel the default kernel, you should test it by rebooting your computer, loading the new kernel, watching the messages to ensure that your hardware has been detected properly, and using it for a few standard tasks, just to make sure that everything is copasetic Upgrading and Customizing the Kernel Summary One of Linux’s most persuasive selling points is the ability it gives you to finetune the kernel for your specific needs Often, it isn’t necessary or advisable to build your own kernel, especially if you have a support agreement for RHEL In such a situation, you’re better off using the officially sanctioned kernels created by Red Hat Software Fedora Core users enjoy more leeway because Fedora Core is neither affiliated with Red Hat (formally) nor supported by Red Hat Consequently, if you’re a Fedora user, you can use binary RPMs provided periodically by the Fedora Project or you can build your own custom kernel The challenge when creating the do-it-yourself kernel is to understand all of the possible configuration options available to you or at least to know which of the options you don’t need Whether you use a prebuilt binary kernel or make your own, make sure that you have a boot disk, perhaps even two, so you can still get into your system if the upgrade process fails 671 CHAPTER 28 Configuring the System at the Command Line IN THIS CHAPTER ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Administering Your System from the Command Line Managing Processes Maintaining the File System Timekeeping Automating Scripts This chapter shows you how to use command line programs to perform system and network administration tasks Using GUI tools for system administration is convenient when such tools are available, but they are not always available and often fail to offer a complete interface to subsystem administration In fact, many GUI administration tools are little more than graphical wrappers around the command line programs you learn to use in this chapter Administrating Your System from the Command Line Why should you learn how to administer your Fedora Core or RHEL system from the command line? First, although the range of available GUI system and network administration tools continues to grow in both number and sophistication, not all administrative tasks have a matching GUI tool, and the available tools are often incomplete, out of date, or as unintuitive and awkward to use as the command line programs they attempt to replace Second, GUI tools are not always available Red Hat systems installed strictly as server machines, rather than desktop or end-user workstations, rarely run the X Window system, much less have it installed They are not only 673 674 Chapter 28 headless, that is, lacking an attached monitor, but they also usually lack an attached keyboard or mouse Running the X Window system on a server uses CPU cycles, RAM, disk space, process table entries, and file descriptors, better used to provide another service Moreover, underpowered systems may lack the horsepower to run the X Window system, and thus GUI tools Another shortcoming of graphical tools is, ironically, the very user-friendliness that makes them so popular That is, graphical administration tools require user interaction; they not readily, if at all, lend themselves to automated, unattended execution They are rarely scriptable or support the capability for making bulk changes, such as adding 25 user accounts in a single operation In contrast, you rarely find a command line tool that cannot be scripted to facilitate bulk system changes or that cannot be automated using cron or another scheduling utility N OT E To be fair, in cases in which GUI tools are available, they can usually be used via X tunneling in ssh (ssh’s -X and -Y options), which makes it possible to use GUI tools to administer a remote system The benefits of automating and simplifying system administration cannot be overestimated In a small environment with few users, workstations, and servers, the inability to script GUI configuration and administration tools may not be an issue However, system maintenance becomes a challenge even at the top end of the small office/home office (SOHO) sector, say 25 users and workstations, two or three servers, and half a dozen printers At large installations with multiple servers, dozens or hundreds of users and workstations, plus all of the associated administrative overhead, administrators, and there are usually several, must be able to make bulk changes and perform system maintenance and administration unattended and automatically To otherwise is inefficient and impractical Fedora Core and RHEL are far from the only Linux systems you’ll encounter Graphical tools with which you are familiar on Fedora Core or RHEL usually don’t exist on, say, a Debian or Novell system Speaking from personal experience, the day will come when you need to administer a non–Red Hat-derived system If you know how to use command line tools and understand the underlying configuration files, you won’t be dependent on the GUI tool and, more importantly, your system administration skills will be considerably more portable In some cases, thankfully less common, GUI tools interfere with system administration tasks because, for example, the modifications they make to a configuration file overwrite manual changes Finally, graphical administration tools, by their very nature, encourage uninformed or ill-informed system administration habits GUI tools deliberately hide complex, often unintuitive configuration files and commands behind an attractive, convenient interface Hiding the complexity does not Configuring the System at the Command Line make it disappear, though In fact, it may make it worse because you never learn how a service really works, how to troubleshoot a misbehaving daemon, or how to customize a program’s behavior using command line options the GUI tool does not support Should you use graphical system administration tools? Absolutely They are helpful, convenient, and timesaving additions to every system administrator’s toolbox Not every problem is a nail, so you need more tools than a hammer GUI tools are only one set of many tools at your disposal You yourself, your employer, your colleagues, and your users a valuable service if you take the time to understand the details of system administration Think of it this way: if the graphical utility for configuring a mission-critical service stops working for some reason, you really want to tell your boss you not know how to fix it? You need to know how to use the perfectly serviceable command line utility T I P Many of the commands and utilities discussed in this chapter reside in /sbin and /usr/sbin, which are not ordinarily in a mortal user’s path Execute the following command to add them to your path: $ export PATH=$PATH:/sbin:/usr/sbin If you use su - to become the root user or login as root directly, /sbin and /usr/sbin will already be part of the path The following sections discuss process management, file system administration, monitoring and controlling system performance, configuring the system logs, keeping the system’s date and time accurate, and writing and using scripts to perform maintenance tasks Because many commands can be used by both normal users and the root user, this discussion focuses on usage and options pertinent to administrative needs Managing Processes Administering processes includes identifying, monitoring, controlling, modifying, and obtaining a variety of information about them The ps, top, and kill commands are the most familiar commands used for working with processes, but there are others that are more focused and, especially in the case of the ps command, probably easier to use This section looks at three categories of commands: ■ ■ Commands used to obtain process information ■ ■ Commands used to send signals, usually the kill signal (SIGKILL), to processes ■ ■ Commands used to modify running processes 675 676 Chapter 28 Obtaining Process Information Process information is easy to obtain, if you know how to get it The commands discussed in this section include the following: ■■ ps — Displays process status ■■ pgrep — Lists the PIDs of processes matching a given pattern ■■ pidof — Displays the PID of the process running a specified program ■■ pstree — Displays processes in a hierarchical format ■■ top — Displays process information and status on an ongoing basis ■■ tload — Displays a text mode load average graph Tables 28-1 through 28-4 borrow the layout of ps’s syntax description from its manual page and organize each group of options into tables based on the options’ purpose However, the following tables omit all GNU long options (those preceded with ) and options related to defining custom output formats ps supports both Unix98 options, which are preceded by a hyphen (-), and BSD options, which lack the initial - Where the functionality is identical or very similar, we omit the BSD options In some cases, apparently identical Unix98 and BSD are listed because the BSD option shows different output from the similarly invoked Unix98 option Table 28-1 Basic Process Selection OPTION DESCRIPTION -N Negates the selection criteria specified with other options -a Selects all processes with a TTY except session leaders -d Selects all except session leaders -e Selects all processes T Selects all processes on the invoking terminal r Selects only running processes x Selects processes without controlling TTYs Table 28-2 Process Selection by Category OPTION DESCRIPTION -C command Selects by the command name matching pattern command -G rgid | name Selects by RGID (Real Group ID) rgid or group name Configuring the System at the Command Line Table 28-2 (continued) OPTION DESCRIPTION -U ruid | name Selects by RUID (Real User ID) ruid or user name -p pid Selects by PID pid -u euid | name Selects by EUID (Effective User ID) euid or user name p pid Selects by PID pid and displays the command line U name Selects processes for user name and displays the command line Table 28-3 Standard Output Formats OPTION DESCRIPTION -f Displays full listing -j Displays output in jobs format -l Displays output in long format j Displays output in job control format l Display long output format s Displays output in signal format v Displays output in virtual memory format Table 28-4 Modifying Output Format OPTION DESCRIPTION -H Shows process hierarchy (forest) -w Displays output in wide format C Uses raw CPU time for %CPU instead of decaying average S Includes some dead child process data (as a sum with the parent) c Shows the true command name e Shows environment after the command f Displays process hierarchy as ASCII art (forest) h Suppresses header lines (repeats header lines in BSD personality) w Displays output in wide format 677 678 Chapter 28 If ps’s plethora of options and arguments seems daunting, the pgrep command provides relief because it provides a simpler interface, enabling you to select processes using simple pattern matching It lists the Process IDs (PIDs) of processes matching the specified pattern You can then use those PIDs with ps’s p or -p options to obtain more information, if you wish pgrep’s syntax is: pgrep [-flnvx] [-P ppid] [-u euid] [-U uid] [-G gid] [pattern] If you specify multiple criteria, the selected processes match all criteria, so keep the selection criteria as simple as possible pattern contains the expression to match against process names or command lines -f matches pattern against the process name (the default if -f is not specified) or the full command line -l causes pgrep to list both the PID and the process name If multiple processes match pattern and other criteria, -n limits the output to the most recently started process -v reverses the matching, showing all processes not matching the specified criteria -x forces an exact match of pattern -P ppid restricts the output to matches with a parent PID of ppid Similarly, -u euid, -U uid, and -G gid, limit the output to processes whose EUIDs, UIDs, and/or GIDs, respectively, match euid, uid, and/or gid Multiple ppids, euids, uids, and gids may be specified by separating each with commas For example, the following pgrep command shows all process that match kio, using the -l option to show the PID and the process name: $ pgrep -l kio 19803 kio_uiserver 15225 kio_file 23092 kio_media 23094 kio_pop3 The next command uses the -v option to show all processes not owned by root or the user bubba: $ pgrep -vlU root,bubba 2113 portmap 2131 rpc.statd 2530 mDNSResponder 2641 ntpd 2712 iiimd 2722 cannaserver 2768 xfs 2798 dbus-daemon 18160 pop3-login 18161 pop3-login 18386 imap-login 18746 imap-login 2165 httpd Configuring the System at the Command Line 2166 httpd 2167 httpd The listing is truncated to preserve space You can combine the options behind a single hyphen, as shown in the example, or specify each individually, that is, pgrep -v -l -U root,bubba pidof enables you to locate the PID of a process by name Its syntax is: pidof [-s] [-x] [-o pid] program program is the base name of the program whose PID(s) you want to find You can specify multiple programs by separating their names with white space -s returns only the first PID located, additional PIDs are ignored -x causes pidof to return the PID(s) of shell scripts running program Specifying -o pid tells pidof to ignore (not to list) one or more PIDs that match pid pstree displays all running processes as a tree, making clear the parent/child relationships between processes Its syntax is: pstree [-a] [-c] [-H pid] [-n] [-p] [-G] [basepid | baseuser] Called with no arguments, pstree shows all processes, with init as the root Specifying basepid or baseuser begins the display from the PID specified by the PID basepid or the username baseuser, respectively -a includes the command line for each process -c expands identically named child processes (such as the mingetty instance spawned for each terminal) -H pid highlights the PID pid and its ancestor (parent) processes If pid does not exist, pstree exits with an error -n sorts the output by PID (the default is by ancestry) -p causes each process’s PID to display and implies -c -G, finally, draws the tree using the VT100 drawing characters rather than the default ASCII characters |, +, -, and ` top displays real-time CPU and memory usage and current system uptime information Although it is an interactive command, top is a vital tool in every system administrator’s toolbox, so its command line interface (not its interactive use) is covered here top [-bcisqS] [-d delay] [-p pid] [-n iter] -d delay specifies the number of seconds between screen updates (default is 5), and -q specifies constant updates, which run at the highest priority if used by the root user -p pid identifies up to 20 PIDs in white-space-delimited pids to monitor top continues to run unless -n iter is specified, iter defining the number of iterations top refreshes its display before exiting (0 is interpreted as 1) -S enables cumulative mode, in which each process’s CPU 679 680 Chapter 28 time is shown as a sum and includes the CPU time of any dead child processes Of course, for a child process’s time to count, it must have died -s runs top in secure mode and disables potentially dangerous commands in the interactive interface, such as k, which can kill processes -i instructs top to omit idle or zombie processes from its display -b, finally, runs top in batch mode and runs until specifically killed or until the number of iterations specified with -n have elapsed (all other command line input ignored) To exit top, press q tload displays a real-time text mode graph of the system’s load average, which is the number of processes waiting to run during the last minute, the last minutes, and the last 15 minutes Its syntax is: tload [-s scale] [ -d delay ] [tty] tload displays its graph to the current terminal, unless tty is specified, when it then becomes tload’s output target -d delay sets the delay between graph updates to delay seconds (if delay is 0, the graph never updates) -s scale sets the vertical height of the graph in scale characters Thus, the smaller the value of scale, the larger the scale To exit from tload, press Ctrl+c Figure 28-1 illustrates tload’s output Signaling Processes The commands this section discusses (see the following list) can be used to send any signal, not just one of the kill signals, to a running process Kill signals are the most common, of course, but the complete list of possible signals is significantly longer This section covers the following commands: ■■ kill — Sends a signal to a process ■■ pkill — Kills or sends another signal to a process matching a given pattern ■■ killall — Kills processes you specify by name Most Linux users are familiar with the kill command Note, however, that most shells, including bash, have a built-in kill command The shell’s kill is executed before /bin/kill in most shells because they execute built-in commands, aliases, and functions, where applicable, before using a command in the PATH The discussion here covers the kill command /bin/kill, not the shell command kill’s syntax is: kill [-s signal | -p] [-a] [ ] pid kill -l Configuring the System at the Command Line Figure 28-1 tload’s graphical process monitor pid is one or more white-space-delimited tokens specifying the processes to kill Each token can be a PID (where pid > 0); a process name; -1, which kills all processes with PIDs between and 35,767; or -pid, which kills all processes in the process group whose PGID (Process Group ID) is pid If you specify -a, all processes matching pid are killed (only root may use -a) -p lists only the PID; no processes are killed -s signal indicates the signal to send; signal can be either a numeric or symbolic name, as shown with kill -l pkill, which has a comparable call interface to pgrep, sends a signal to one or more processes matching a given pattern Its syntax is: pkill [-signal] [-fnvx] [-P ppid] [-u euid] [-U uid] [-G gid] [pattern] If you specify multiple criteria, the selected processes match all criteria, so keep the selection criteria as simple as possible pattern contains the expression to match against process names or command lines -signal specifies the numeric or symbolic signal to send (SIGTERM is the default) -f matches pattern against the process name (the default if -f is not specified) or the full command line If multiple processes match pattern and other criteria, -n sends the signal to the most recently started process -v reverses the matching, showing all processes not matching the specified criteria -x forces an exact match of pattern -P ppid sends the signal to processes whose parent process has a PID of ppid Similarly, -u euid, -U uid, and -G gid send the signal to processes whose EUIDs, UIDs, and/or GIDs, respectively, match euid, uid, and/or gid Multiple ppids, euids, uids, and gids may be specified by separating each with commas 681 682 Chapter 28 killall kills all processes matching a name Its syntax is: killall [-l] | [-giqvw] [-signal] name Specifying -l lists the numeric value and symbolic names of all recognized signals, and it cannot be used with any other options or arguments name lists the command whose process should be signaled Multiple names may be specified if separated by white space -signal specifies the signal to send; SIGTERM is the default -g kills the process group to which name belongs -i runs killall in interactive mode and requests confirmation for each name signaled -q suppresses error messages if no processes match name -v displays a short message if the signal was sent successfully -w instructs killall to wait for each name to die Modifying Process Priorities In some cases it is not necessary to terminate a process, but simply to modify the priority at which it runs The following two commands accomplish this goal: ■■ nice — Starts a program with a given scheduling priority ■■ renice — Alters the scheduling priority of one or more running processes The nice command enables you to start a program with a higher or lower nice number, which controls how much CPU time the kernel gives a program relative to other programs with the same priority The nice command’s syntax is: nice [-n value | -value] [prog [arg]] prog is the program to run arg lists the arguments to prog, and it is specified using the format prog understands value expresses the modified nice number at which to run prog Valid values for value are -20 to 19, with smaller values representing a higher priority relative to other programs Use the renice command to modify the CPU scheduling priority of a running process Its syntax is: renice priority [[-p] pid] [[-g] pgrp] [[-u] user] priority expresses the new nice number at which to run the specified process(es) -p pid identifies the processes to modify by PID -g pgrp modifies all processes in the process group pgrp -u user causes all processes owned by user to run at the new priority Configuring the System at the Command Line Maintaining the File System A significant portion of routine administrative time and effort involves file system maintenance These tasks include modifying existing file systems, creating new ones, fixing broken ones, monitoring all of them, and ensuring that users not monopolize any of them The file system maintenance commands this section covers have been divided into three categories: commands for creating and maintaining file systems, commands for working with files and directories, and commands for managing disk space usage Working with File Systems Unless you have an extremely active system, creating and formatting a file system is an infrequent necessity Actively maintaining a file system, however, is an ongoing process The commands for creating, formatting, and checking the integrity of Fedora Core and RHEL file systems discussed in this section are: ■ ■ Working with partitions ■ ■ ■ ■ ■ ■ fdisk — Creates, deletes, and modifies hard disk partitions parted — Edits hard disk partition tables Working with file systems ■ ■ ■ ■ mkswap — Creates a swap partition or file ■ ■ e2fsck — Checks, and optionally repairs, a Linux file system ■ ■ resize2fs — Resizes ext2 and ext3 file systems ■ ■ ■ ■ me2kfs — Creates a file system on a device symlinks — Validates, and optionally repairs, symbolic links Mounting and unmounting file systems ■ ■ mount — Mounts a file system ■ ■ umount — Unmounts a file system ■ ■ swapoff — Disables a swap partition or file ■ ■ swapon — Enables a swap partition or file Creating and Manipulating Partitions The fdisk program prepares hard disks to hold Linux file systems fdisk is an interactive program that accepts few command line options You can invoke it using one of the following forms: 683 684 Chapter 28 fdisk -s partition fdisk [-lu] device The first form uses the -s option to display the size in (blocks) of the disk partition specified by partition and then exits The second form operates on the disk specified by device The -l option lists the disk geometry of device, followed by a columnar list of each partition on device showing each partition’s boot status, starting and ending cylinders, total size (in 512byte blocks), and the partition type If device is omitted, fdisk lists the same information based on the contents of the file /proc/partitions The -u option instructs fdisk to show disk and partition sizes in terms sectors instead of cylinders Omitting -l (second form) starts an interactive fdisk session on device The parted program manipulates existing partitions You can use it check, create, delete, resize, move, and copy the following partition types: ■■ ext2 ■■ ext3 ■■ FAT ■■ FAT32 ■■ Linux swap parted’s general syntax is: parted [opts] [dev [cmd [cmd_opts]]] To force parted to run in interactive or batch (script) mode, opts may be -i or -s, respectively Interactive mode is the default dev can specify any block device on which partitions can be created, such /dev/hdb or /dev/sdc or even a floppy disk (/dev/fd0) The parted rubber meets the road with the cmd argument and any associated command options specified in cmd_opts Table 28-5 lists possible parted commands Table 28-5 GNU parted Commands COMMAND DESCRIPTION check Checks a partition cp Copies the contents of one partition to another help Prints parted usage instructions mkfs Creates a file system on a partition ... /usr/src/redhat/BUILD Wrote: /usr/src/redhat/RPMS/i686/kernel-2.6.10-1 .77 0_FC3.root.i686.rpm Wrote: /usr/src/redhat/RPMS/i686/kernel-smp2.6.10-1 .77 0_FC3.root.i686.rpm Wrote: /usr/src/redhat/RPMS/i686/kernel-debuginfo2.6.10-1 .77 0_FC3.root.i686.rpm... using the Red Hat Network, you must first register your system with Red Hat by using the Red Hat Network registration client N OT E You can also register for the Red Hat Network at the Red Hat Web... Keeping Your System Updated with up2date and the Red Hat Network IN THIS CHAPTER ■ ■ ■ ■ ■ ■ Using the RedHat up2date Agent Registering Your System with the Red Hat Network Accessing the Red Hat Network