Finding Process Startups

While the ps command can list what is running now, and other tools show what resources are being used, there is no good tool for telling how something started in the first place. Although ps can identify the PPID, in many cases the PPID is 1-indicating init owns it. Instead, there are plenty of places where a process can be started, including boot scripts, device configuration scripts, network changes, logins, application initialization scripts, and scheduled tasks.

Inspecting Boot Scripts

The directory /etc/init.d/ contains scripts for starting and stopping system services (these are detailed in Chapter 3). These scripts are activated by links in the different rc directories (/etc/rc0.d, /etc/rc1.d, and so on). As init enters each run level, the appropriate S links are executed. For example, at run level 1, all S links in /etc/rc1.d/ are started. This includes S20single for single-user mode configuration. When the system changes levels, all K (for kill) scripts are executed before changing run levels. To find the current run level, you can either use who -r or the runlevel command.

Note 

The runlevel command displays the previous and current run levels. Usually the previous one is not defined (since you probably booted into the current level) and is displayed as an N (for not defined).

 $ who -r          run-level 2 2006-09-28 20:32                 last=S $ runlevel N 2 

During boot, all output from the init scripts is sent to /var/log/messages. You can use this log file to identify which processes were executed.

Note 

Under Dapper Drake and earlier Ubuntu versions, init is the top-most process and is critical for managing running processes. New to Edgy Eft, the System V init is being replaced with Upstart-an event driven process manager.

Inspecting Device Startups

Dynamic device configuration is managed by udev (see Chapter 3). The udev process watches and manages plug-and-play devices. Based on the configuration in /etc/udev/rules.d/, different applications may be launched.

Inspecting Network Services

New network interfaces are managed by a couple of different systems. First, udev identifies the network interface (/etc/udev/rules.d/25-iftab.rules). This rule runs the interface table helper (iftab_helper) command. The helper consults the file /etc/iftab in order to identify the proper device handle. After the interface is identified, it can be brought up or down. There are four directories of scripts for managing network interfaces:

• /etc/network/if-pre-up.d/-This contains steps that must be completed before (pre) the interface is brought up. For example, the scripts may need to load wireless drivers.

• /etc/network/if-up.d/-These scripts are used after bringing up the configured network interface. For example, this is where the system clock is set-every time any network is brought up, the computer's clock is set.

• /etc/network/if-down.d/-These scripts are used to remove any running configuration. For example, if you have the Postfix mail server running, then there is a script that tells Postfix to reload its configuration when an interface is taken down.

• /etc/network/if-post-down.d/-This directory contains any cleanup stages that are needed after (post) the interface is taken down. For example, unnecessary wireless drivers can be unloaded.

Tip 

The /etc/network/ scripts are used when an interface is brought up and down. The /etc/init.d/networking script is used to actually bring up and down the interfaces. Interfaces are configured based on the /etc/network/interfaces file, described in Chapter 11.

Although /etc/network/ is used only when interfaces are brought up or down, other programs like xinetd can run applications based on network connections. If you installed xinetd (sudo apt-get install xinetd), the configuration file /etc/xinetd.conf and the /etc/xinetd.d/ directory contain the list of executables that can be started by xinetd.

Inspecting Shell Startup Scripts

Each time you log in, log out, or create a new shell, configuration scripts are executed. Each of these scripts run processes. Since bash is the default shell under Ubuntu, you are likely to use the configuration scripts in Table 7-1.

Table 7-1: Shell Startup Scripts
Open table as spreadsheet

Initialization Script	Purpose
/etc/profile	Used by every login shell, system-wide.
$HOME/.bash_profile	Used on a per-user basis. Each user can have a personalized login script.
/etc/bash.bashrc	Every interactive shell runs this system-wide configuration script.
$HOME/.bashrc	Every interactive shell runs this user-specific configuration script.
/etc/bash.logout	If you create it, this system-wide script is executed every time a user logs out.
$HOME/.bash_logout	User-specific script that is used during logout.

All of these scripts are divided into two situations: login/logout and interactive shells. Whenever you log into your Ubuntu system, the login and interactive shell scripts are executed. When you open a terminal window, only the interactive scripts are used.

Tip 

The default user-specific shell scripts are stored in /etc/skel/. Use ls -la /etc/skel/ to list all of the default files. Changing these defaults will give all new user accounts the modified configuration files, but you will still need to modify existing user accounts. For system-wide changes, modify /etc/profile and /etc/bash.bashrc instead.

Inspecting Desktop Scripts

Beyond user-level shell scripts, the graphical desktop can also run scripts. First, X-Windows runs. This starts up applications by running the script /etc/X11/xinit/xinitrc, /etc/X11/ Xsession, and /etc/X11/xinit/xserverrc. Each of these scripts set environment variables and can run applications. There are also startup scripts in /etc/X11/Xsession.d/ that are started after a user logs in, and individual users can have a $HOME/.xsession script for running applications at startup.

After X-Windows, the desktop starts. Under Ubuntu, this is Gnome. Gnome runs lots of applications that, in turn, can run many more applications. The main places to look for automatically running Gnome processes are in the /etc/X11/gdm/ directory, in the file $HOME/.gnomerc, and under System Preferences Sessions. The /etc/X11/gdm directory contains system-wide startup scripts. The $HOME/.gnomerc script enables you to configure your own startup applications, and the graphical session configuration tool (see Figure 7-4) enables you to easily customize non-standard startups.

Figure 7-4: The Gnome graphical session manager showing the list of startup applications

All of these startup options can become very confusing. For example, if you want to automatically start Firefox on login, then you can add it to /etc/X11/Xsession, /etc/X11/gdm/ Xsession, /etc/X11/gdm/PostSession/Default, /etc/X11/Xsession.d/99start_ firefox, $HOME/.xsession, $HOME/.gnomerc, or use the graphical Gnome Session editor to add a startup applications. The main question to ask is, "who will want this?"

• Everyone running X-Windows?-Use /etc/X11/Xsession or place the startup script under /etc/X11/Xsession.d/.

• Just you running X-Windows?-Use $HOME/.xsession.

• Everyone running Gnome?-Use /etc/X11/gdm/PostSession/Default. This will work for Gnome users, but not KDE or other desktops. KDE, XDM, and other desktops have their own configuration directories and files.

• Just you running Gnome?-Use $HOME/.gnomerc or the graphical session editor.

Note 

These are not all of the possible startup hooks. There are plenty of places where code can be told to start running. If you are trying to find where an application starts, look here first or use ps and start tracking down parent processes. Most graphical processes use configuration files and any of those files could potentially run applications.

Inspecting Gnome Applications

Just as udev watches for plug-and-play devices, so does Gnome. The Gnome desktop can identify some devices and automatically run applications. The default settings are found under System Preferences Removable Drives and Media. The tabs show you the items you can change:

• Storage-When a CD-ROM is inserted, the default action is to either browse the disk or start the CD-ROM burner (see Figure 7-5). I usually disable the option Burn a CD or DVD when a blank disc is inserted. This does not disable your ability to right-click on an ISO image and select the burn option-it only stops the default CD-Writer application from starting. This tab also covers other types of removable media, including USB thumb drives.

  
  Figure 7-5: The Removable Drives and Media preferences, showing drive handlers

• Multimedia-When you first insert an audio CD or a DVD, the default media player starts up. From the Multimedia tab (see Figure 7-6), you can change the default applications or disable the automatic startup. If you disable it, you can still run the multimedia players from the Applications Sound & Video menu.

  
  Figure 7-6: The Removable Drives and Media preferences, showing the default audio and video applications

• Cameras-When a camera is connected, the default action is to import pictures (see Figure 7-7). On my main workstation, I usually disable this option-if I want to import pictures, then I will do it myself. This is because I usually want to download a single, specific picture, and not all of them. In contrast, my laptop is configured to automatically import pictures since I am probably traveling and want to quickly transfer pictures before taking more photos.

  
  Figure 7-7: The Removable Drives and Media preferences, showing the default camera settings

• PDAs-If you have a PDA such as a Palm or PocketPC, then you can automatically connect and synchronize with these devices.

• Printers & Scanners-If you have a USB scanner or printer, then it may not always be connected. Normally, no programs (beyond udev) run when a printer is attached, but you could enable the default setting and add the printer to the printing system. For scanners, xsane automatically runs. You can change the default action that occurs when these devices are attached (see Figure 7-8).

  
  Figure 7-8: The Removable Drives and Media preferences, showing the default actions for printers and scanners

• Input Devices-This is an interesting tab because it really does not do anything. In theory, you can connect a USB mouse, keyboard, or tablet and have an application run. In practice, the X-Windows server normally uses these devices. If they are not configured and connected before the X-server starts, then they will not be recognized as pointer devices (see Chapter 3 for configuring pointer devices). However, if you have a special application that can handle the device, then you can use these settings to run the application.

Although other spawning subsystems, such as udev and /etc/init.d/, are configurable and extendable, Gnome is fairly inflexible. You can only configure auto-run settings for items listed in this applet. If you have a new plug-and-play device that is not listed (for example, a GPS system) then you cannot make Gnome spawn an application. Instead, you will need to configure udev run the application.

Tip 

Configuring udev to run programs is covered in Chapter 3. See the section on Associating Applications with USB.

Inspecting Schedulers: at, cron, and anacron

Programs that should run periodically are usually placed in a scheduler. The three common schedulers are at, cron, and anacron.

Scheduling with at

The at command specifies that an application should run at a specific time. This is used for run-once commands. For example, to start xclock in 15 minutes, you could use:

 echo "DISPLAY=:0 xclock" | at now + 15 minutes 

The at command takes one or more command-line statements as input. The time format can either be in an HH:MM with am or pm (for example, 3:45 pm or 3:45 PM), a date format (for example, 03/15/07), or as an offset (for example, noon + 3 hours or 8am + 6 days). Scheduled at jobs are stored in the /var/spool/cron/atjobs/ directory. You can query them using atq and remove jobs using atrm. After the process runs, any text output is e-mailed back to the user.

Scheduling with cron

While at is used for one-time applications, cron is used for repeated tasks. Each user has a crontab entry where processes can be scheduled. For example, mine has this entry:

 3,18,33,48 * * * * fetchmail -U -n --invisible > /dev/null 2>&1 

Each cron entry has six elements per line. The first five specify when to run, and the last element is a single command line to actually execute. The time fields are:

• Minute-The minute to run. This can be a single value (0-59) or a comma-separated list of times (for example, 3,18 means run at 3 and 18 minutes after the hour). A star can also be used to mean every minute.

• Hour-The hour to run. This can be a single value (0-23), a range (for example, 9-17 means hourly from 9 am to 5 pm), a comma-separated list, or a division indicating how often. For example, 9-17 means hourly from 9 am to 5 pm, but 9-17/3 means every 3 hours between 9 am and 5 pm (9 am, 12 pm, and 3 pm). A star can be used to mean every hour, and when combined with a divisor, "*/4 means every four hours.

• Day-Day of the month to run. As with the other fields, this can be a single value (1- 31), a range, or a list and can use a divisor. A star means every day.

• Month-Month of the year to run. This can be a single value (1-12), a range, or a list and can use a divisor. A star means every month.

• Day of week-You can specify which weekday to run on. The days are numbers: 0-6 for Sunday through Saturday (7 can also mean Sunday). Again, this can be a value, list, or range and may include a divisor.

Usually the date specification is simple. For example, 0 12 * * 0 means to run every Sunday at noon. But it can be very complex: */3 */3 */3 */3 */3 says to run every three minutes, every third hour of every third day in every third month, but only when it corresponds with every third day of the week.

Tip 

Try to space cron jobs so they do not all run at once. Although I could use */15 to run fetchmail four times per hour, I use the list 3,18,33,48 instead. This prevents lots of applications from all trying to start on the hour.

To schedule a cron task, use crontab -e. This edits your crontab file (found in /var/ spool/cron/crontabs/). You can also use crontab -l to list your crontab entries. A # at the beginning on a crontab line is a comment. I usually put the following comment at the start of my file just so I can remember what the time fields mean:

 # mm ss DD MM WW command 

As with at, every text output from the cronjob is e-mailed back to the user. If you don't want to receive e-mail, then add > /dev/null 2>&1 to the end of the command. This directs all output to /dev/null.

Scheduling with anacron

While cron runs tasks repeatedly, it makes no distinction as to the system state. The anacron service is similar to cron, but allows tasks to be run based on a relative period rather than an absolute date. For example, the default anacron installation runs updatedb (to update online man-page indexes) daily, starting at five minutes after the computer first boots up.

The configuration schedule for anacron is found in the /etc/anacrontab file. The default scripts are in /etc/cron.d/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/.

If you run a mission-critical system, or a computer with limited resources, then you should seriously consider looking at these configuration settings and tuning them to your needs. For example, if it is a deployed server, then you probably do not need updatedb running daily. In fact, you could disable anacron completely and move any required functionality into root's crontab (sudo crontab -e). This way, tasks such as log file rotation will happen on a predictable schedule.