Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

chkconfig - updates and queries runlevel information for system services

News

Startup and Shutdown

Recommended Books Recommended Links Runlevels  init.d scripts Xinetd
service YaST Admin Horror Stories

Linux Tips

Humor Humor Etc

Most Linux distributions include the chkconfig command for managing runlevel services. The syntax for chkconfig is specified in the chkconfig man page.

For example, use chkconfig to configure the OpenSLP daemon, slpd, to start in runlevels three and five only. Do the following:

1. Check if slpd is on in the current runlevel

# chkconfig slpd
slpd on

2. Check slpd's configuration for every runlevel.

# chkconfig -l slpd
slpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

3. Turn slpd on in runlevels three and five.

#chkconfig slpd 35

chkconfig - updates and queries runlevel information for system services

chkconfig --list [name]
chkconfig --add
name
chkconfig --del
name
chkconfig
[--level levels] name <on|off|reset>
chkconfig
[--level levels] name

chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.

This implementation of chkconfig was inspired by the chkconfig command present in the IRIX operating system. Rather than maintaining configuration information outside of the /etc/rc[0-6].d hierarchy, however, this version directly manages the symlinks in /etc/rc[0-6].d. This leaves all of the configuration information regarding what services init starts in a single location.

chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, changing the startup information for services, and checking the startup state of a particular service.

When chkconfig is run without any options, it displays usage information. If only a service name is given, it checks to see if the service is configured to be started in the current runlevel. If it is, chkconfig returns true; otherwise it returns false. The --level option may be used to have chkconfig query an alternative runlevel rather than the current one.

If one of on, off, or reset is specified after the service name, chkconfig changes the startup information for the specified service. The on and off flags cause the service to be started or stopped, respectively, in the runlevels being changed. The reset flag resets the startup information for the service to whatever is specified in the init script in question.

By default, the on and off options affect only runlevels 2, 3, 4, and 5, while reset affects all of the runlevels. The --level option may be used to specify which runlevels are affected.

Note that for every service, each runlevel has either a start script or a stop script. When switching runlevels, init will not re-start an already-started service, and will not re-stop a service that is not running.

chkconfig also can manage xinetd scripts via the means of xinetd.d configuration files. Note that only the on, off, and --list commands are supported for xinetd.d services.

Options

Runlevel Files

Each service which should be manageable by chkconfig needs two or more commented lines added to its init.d script. The first line tells chkconfig what runlevels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any runlevels, a - should be used in place of the runlevels list. The second line contains a description for the service, and may be extended across multiple lines with backslash continuation.

For example, random.init has these three lines:

# chkconfig: 2345 20 80
# description: Saves and restores system entropy pool for \
#              higher quality random number generation.
This says that the random script should be started in levels 2, 3, 4, and 5, that its start priority should be 20, and that its stop priority should be 80. You should be able to figure out what the description says; the \ causes the line to be continued. The extra space in front of the line is ignored.

Adjust set of daemons which start at each runlevel

As stated earlier, the chkconfig command can be used to adjust which daemons start at each runlevel. You can use this command with the --list switch to get a full listing of daemons listed in /etc/init.d and the runlevels at which they will be on or off:

# chkconfig --list
keytable 0:off 1:on  2:on  3:on 4:on  5:on 6:off
atd      0:off 1:off 2:off 3:on 4:on  5:on 6:off
syslog   0:off 1:off 2:on  3:on 4:on  5:on 6:off
gpm      0:off 1:off 2:on  3:on 4:on  5:on 6:off
kudzu    0:off 1:off 2:off 3:on 4:on  5:on 6:off
wlan     0:off 1:off 2:on  3:on 4:on  5:on 6:off
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
netfs    0:off 1:off 2:off 3:on 4:on  5:on 6:off
network  0:off 1:off 2:on  3:on 4:on  5:on 6:off
random   0:off 1:off 2:on  3:on 4:on  5:on 6:off
...
...

chkconfig Examples

You can use chkconfig to change runlevels for particular packages. Here we see sendmail will start with a regular startup at runlevel 3 or 5. Let's change it so that sendmail doesn't startup at boot.

Use Chkconfig to Get a Listing of sendmail's Current Startup Options

The chkconfig command can be used with grep to determine the run levels in which sendmail will run. Here we see it will run at levels 3 and 5.

# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
#

Switch Off sendmail Starting Up in Levels 3 and 5

The chkconfig command with the --level switch indicates that some action needs to be done at the runlevels entered as its values. The first argument in the command is the package you want to affect and the second defines whether you want it on or off. In this case we want sendmail not to be started when entering runlevels 3 and 5:

# chkconfig --level 35 sendmail off
#

By not specifying the runlevels with the --level switch, chckconfig will make the changes for runlevels 3 and 5 automatically:

# chkconfig sendmail off

Because the intention is to permanently shutdown sendmail permanently, we might also have to stop it from running now.

# service sendmail stop
Shutting down sendmail: [  OK  ]
Shutting down sm-client: [  OK  ]
#

Double-check that sendmail Will Not Start Up

We can then use chkconfig to double-check our work.

# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off
#

Turn On sendmail Again

To reactivate sendmail, we can use chkconfig once more, but with the on argument. Start sendmail again to get it running immediately, not just after the next reboot.

# chkconfig sendmail on
# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
# service sendmail start
Starting sendmail: [  OK  ]
Starting sm-client: [  OK  ]
#

Using chkconfig to Improve Security

A default Fedora installation automatically starts a number of daemons that you may not necessarily need for a Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.

The screen output of the netstat -an command below shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?

# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State
tcp    0    0 0.0.0.0:32768    0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:32769  0.0.0.0:*     LISTEN
tcp    0    0 0.0.0.0:111      0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:631    0.0.0.0:*     LISTEN
tcp    0    0 127.0.0.1:25     0.0.0.0:*     LISTEN
tcp    0    0 :::22            :::*          LISTEN
udp    0    0 0.0.0.0:32768    0.0.0.0:*
udp    0    0 0.0.0.0:930      0.0.0.0:*
udp    0    0 0.0.0.0:68       0.0.0.0:*
udp    0    0 0.0.0.0:111      0.0.0.0:*
udp    0    0 0.0.0.0:631      0.0.0.0:*
...
...
#

For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command which lists all open, or actively used, files and can be given additional options to extend its scope to include the TCP/IP protocol stack.

In the next examples we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd and ntp daemons respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS", and 30, "Configuring NIS". portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. NTP, which is covered in Chapter 24, "The NTP Server", is required for synchronizing your time with a reliable time source, and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and xinetd", and it might be required for their operation:

# lsof -i tcp:111
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
portmap 1165  rpc    4u  IPv4   2979       TCP *:sunrpc (LISTEN)
[root@ bigboy tmp #
 
# lsof -i tcp:32769
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
xinetd  1522 root    5u  IPv4   2764       TCP probe-001:32769 (LISTEN)
#
 
# lsof -i udp:123
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
ntpd    1321  ntp    4u  IPv4   3390       UDP *:ntp
...
...
#

In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently.

# lsof -i tcp:32768
COMMAND    PID    USER   FD   TYPE DEVICE SIZE NODE NAME
rpc.statd 1178 rpcuser    6u  IPv4   2400       TCP *:32768 (LISTEN)
# ls /etc/init.d/rpc.statd
ls: /etc/init.d/rpc.statd: No such file or directory
# grep -i statd /etc/init.d/*
/etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0
...
...
#

As a rule of thumb, applications listening only on the loopback interface (IP address 127.0.0.1) are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address 0.0.0.0, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shutdown nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers", for details). Your needs may be different.

Remember to thoroughly research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books and the Internet for information. Unpredictable results are always undesirable.

Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.

Final Tips on chkconfig

Remember the following:

 

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

init(8) ntsysv(8) system-config-services(8)

service



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019