g an application from the command line
$ ./catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar $ ./catalina.sh stop ..................................................................... $ sh catalina.sh start Using CATALINA_BASE: /opt/apache-tomcat-7.0.26 Using CATALINA_HOME: /opt/apache-tomcat-7.0.26 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.26/temp Using JRE_HOME: /usr Using CLASSPATH: /opt/apache-tomcat-7.0.26/bin/bootstrap.jar: /opt/apache-tomcat-7.0.26/bin/tomcat-juli.jar
Consider starting a typical Hypertext Transfer Protocol (HTTP) web server. In Linux, any port less than port 1024 is considered a privileged port, and only root can open privileged ports. Because web servers by default run on port 80, root needs to start the process. As noted, however, it is considered insecure to run a service as the root user. The correct procedure is to start the service as root and then hand it off to a standard user or service account.
Fortunately, a lot of server services have the scripts in place to do just
that. If you build the Apache web server from source, you find it starts
as root and then hands off the httpd threads to the
Listing 2 starts a default compilation of the Apache 2
web server. The install process does a few things, including making the
apachectl command executable. Because this
process requires use of port 80, it starts with root user privileges.
ps command reveals the httpd
processes are running under the apache user account.
Listing 2. Starting the Apache web server
# cd /usr/local/apache2/bin # apachectl start #ps aux | grep httpd apache 23094 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23095 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23096 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23097 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start apache 23098 0.0 0.3 11784 1912 ? S 10:41 0:00 /usr/sbin/httpd -k start
Running applications in the background
Some installed software might not be as user friendly as the Apache web server. Unless you are troubleshooting or otherwise want to see exactly what is going on with an application, you probably want to run it in the background after the process starts. If you don't, the application terminates when the shell is closed. When running server services, it's not desired behavior for the service to stop every time you close the terminal shell or otherwise log out!
If you run an application in the background, it continues to work even if
you close the shell window. You can start an application in the background
by appending an ampersand (
&) at the end of
the execute command. For example, you can open a file with the vi editor
and run it in the background with the
vi /etc/sysconfig/network & command
& opens the /etc/sysconfig/network
file and keeps it in the background. You can use the
nohup utility to allow the process to continue
even after you logout. For example,
nohup vi /etc/sysconfig/network &.
Listing 3 opens a file for editing in the Vim editor and places it in the background.
Listing 3. Running an application in the background
# vi /etc/sysconfig/network &  24940 # jobs + Stopped vi /etc/sysconfig/network
You can type the
jobs command to see all the
applications you have running in the background. Each job running in the
background is assigned a sequential number, starting at 1. The job in
Listing 3 is job number 1.
24940 is the process ID (PID). You can bring an
application to the foreground with the
command and the specific job number. In this example, the process is not
in use by the user, so it displays as
However, the command
fg 1 opens the terminal
back to the active process of editing the file.
Running applications from the desktop
Running graphical user interface (GUI) applications from the desktop in Linux isn't much different from