linux admin week 5

UEFI serves a similar role to BIOS and has replaced BIOS in most modern systems. For most end users, the difference is negligible, except that if you have a UEFI computer, you may need to do some research to install Ubuntu. UEFI firmware often has a BIOS-mode that allows the firmware to work like a traditional BIOS and that is more easily compatible, especially if you are installing Ubuntu as the sole operating system on the computer, rather than as a dual-boot. There were some significant problems early on, but those seem to have lessened as the Linux community learned more about UEFI and made things more easily compatible. To learn more, especially if you are having trouble, see https://help.ubuntu.com/community/UEFI.

One interesting aspect of using UEFI involves hard disk partitioning. When UEFI is used with Windows 8.x or 10, often the partitioning is set up using GPT (GUID Partition Table) rather than the existing MBR (master boot record) standard. You can use GPT with Ubuntu, but if only Ubuntu is to be installed on the drive, it is often easier to reformat the hard disk to use MBR. As with BIOS and UEFI, most people do not need to know or care whether they are using MBR or GPT. To learn more, see http://www.howtogeek.com/193669/whats-the-difference-between-gpt-and-mbr-when-partitioning-a-drive/.

The boot loader locates the Linux kernel on the disk and loads it into memory. After that task is completed, the boot loader passes control of the system to the Linux kernel. You can see how one process builds on another in an approach that enables many different operating systems to work with the same hardware.

Understanding init Scripts and the Final Stage of Initialization

case "$1" in

start)

start

;;

stop)

stop

;;

restart)

restart

;;

reload)

reload

;;

status)

rhstatus

;;

condrestart)

[ -f /var/lock/subsys/smb ] && restart :

;;

*)

echo $"Usage: $0 {start stop restart status condrestart}"

exit 1

esac

Each /etc/init.d script, or init script, contains logic that determines what to do when receiving a start or stop value. The logic might be a simple switch statement for execution, as in this example:

Although you can use the scripts to customize the way that the system runs from power-on, absent the replacement of the kernel, this script approach also means that you do not have to halt the system in total to start, stop, upgrade, or install new services.

Note that not all scripts use this approach and that other messages might be passed to the service script, such as restart, reload, or status. Also, not all scripts respond to the same set of messages (with the exception of start and stop, which they all have to accept by convention) because each service might require special commands.

After all the system scripts have been run, your system is configured and all the necessary system services have been started. If you are using a runlevel other than 5, the final act of the init process is to launch the user shell—bash, tcsh, zsh, or any of the many command shells available. The shell launches and you see a login prompt on the screen.

Troubleshooting Runlevel Problems

Reordering or changing system services during a particular runlevel is rarely necessary when using Ubuntu unless some disaster occurs. But system administrators should have a basic understanding of how Linux boots and how services are controlled in order to perform troubleshooting or to diagnose problems. By using additional utilities such as the dmesg less command to read kernel output after booting or by examining system logging with cat /var/log/messages less, it is possible to gain a bit more detail about what is going on when faced with troublesome drivers or service failure.

Using the kill Command to Control Processes

The kill command is a basic UNIX system command. You can communicate with a running process by entering a command into its interface, such as when you type into a text editor. But some processes (usually system processes rather than application processes) run without such an interface, and you need a way to communicate with them as well, so you use a system of signals. The kill system accomplishes that by sending a signal to a process, and you can use it to communicate with any process. The general format of the kill command is as follows: matthew@seymour:~$ kill option PID

This tells the process with PID to stop; you supply the actual PID. However, without a signal option, there is no guarantee that a process will be killed because programs can catch, block, or ignore some terminate signals (and this is a good thing, done by design).

matthew@seymour:~$ kill -9 PID

This includes a signal for kill that cannot be caught (9 is the number of the SIGKILL signal); you can use this combination when the plain kill shown previously does not work. Be careful, though. Using this does not allow a process to shut down gracefully, and shutting down gracefully is usually preferred because it closes things out that the process might have been using and ensures that things such as logs are written before the process disappears. Instead, try this first.

matthew@seymour:~$ kill -1 PID

This is the signal to “hang up”—stop—and then clean up all associated processes as well (1 is the number of the SIGHUP signal).

In fact, some system administrators and programmers prefer something like this progression of signals:

kill -15 sends a SIGTERM, which is a clean shutdown that flushes data that needs to be written to disk, cleans up memory registers, and closes the PID.

kill -1, mentioned above, sends a SIGHUP, which cleans up and usually also causes the program to restart.

kill -2 sends a SIGINT, which is an interrupt from the keyboard, the equivalent to sending a CTRL+C. Say you want to stop a program that is running in the background as a daemon instead of in the terminal foreground, this is a good way to do it.

kill -11 sends a SIGSEGV, which causes the problem to experience a segmentation fault and close. It does not flush data to disk, but it may create a core dump file that could be useful for debugging and learning why the program was misbehaving (or behaving exactly as you told it to behave, but not as you intended it to behave).

kill -9 sends a SIGKILL, which should be used as a last resort because it does not sync any data. Nothing is written to disk, no logging, no debugging, nothing. You stop the PID (usually, but not always), but you get nothing that helps you either save data that needed to be written to disk or assists you in figuring out what happened.

As you become proficient at process control and job control, you will learn the utility of a number of kill options. You can find a full list of signal options in the kill man page.

Rotating Log Files

Log files are great, but sometimes they can get unwieldy as time passes and more information is logged. Rotating log files prevents that problem. Rotating a log file means to archive the current log file, start a fresh log, and delete older log files. This means you always have a current log file to peruse, the previous log file, and that the log files never grow too large.

Typically, log rotation is set up by an administrator to happen nightly, at a time when the system is not being heavily used. This is done with a utility called logrotate, running as a cron job (cron is described in Chapter 14, “Automating Tasks and Shell Scripting”).

Ubuntu comes with logrotate installed. There is a cron job already set as well. You can find the script at /etc/cron.daily/logrotate. This file is a bash script and looks like this:

#!/bin/sh

# Clean nonexistent log file entries from status filecd /var/lib/logrotatetest -e

status touch statushead -1 status > status.cleansed 's/"//g' status while read

logfile datedo [ -e "$logfile" ] && echo "\"$logfile\" $date"done >> status.cleanmv

status.clean status

test -x /usr/sbin/logrotate exit 0/usr/sbin/logrotate /etc/logrotate.conf