Rate this page

Flattr this

Cause a system service to reload its configuration

Content

Tested on

Debian (Lenny)
Ubuntu (Lucid, Maverick)

Objective

To cause a system service to reload its configuration, preferably with minimal disruption to that service.

Background

A typical example of a system service is the Apache HTTP server. This consists of a set of background processes (daemons) which are started when the machine boots and stopped when it is shut down. The operation of the service is governed by a set of configuration files which are read when the service is started.

Changes made to the configuration of a service do not necessarily take effect immediately: it may be necessary for a SIGHUP to be sent, or for the relevant processes to be killed then restarted.

At the time of writing (January 2011) there are two mechanisms in common use for managing system services: System V-style init scripts and Upstart. Most of the major GNU/Linux distributions are in the process of migrating from the former to the latter.

Method

Determine the name of the service

Every service has a name that is used to identify it. This is not necessarily the same as the name of the package from which it was installed, or any of the background processes it may spawn. Different distributions may choose different names for the same service.

The following table lists the names used by Debian (Lenny), Ubuntu (Lucid), CentOS (5.5) and SUSE (11.3) for some of the services you are most likely to encounter:

Service Debian Ubuntu CentOS SUSE
Apache apache2 apache2 httpd apache2
BIND bind9 bind9 named named
cron cron cron crond cron
CUPS cups cups cups cups
DHCP dhcp3-server dhcp3-server dhcpd dhcpd
(X)inetd openbsd-inetd openbsd-inetd xinetd xinetd
MySQL mysql mysql mysqld mysql
NFS nfs-kernel-server nfs-kernel-server nfs nfs
NTP ntp ntp ntpd ntp
PostgreSQL postgresql-8.3 postgresql-8.4 postgresql postgresql
SSH ssh ssh sshd sshd
(r)syslog rsyslog rsyslog syslog syslog

If you know the name of the package that provides the service then you can find the service name by listing the files in that package and searching for ones with a pathname starting with /etc/init.d/, /etc/rc.d/init.d/ or /etc/init/. On Debian-based systems this can be done using dpkg, for example:

dpkg --listfiles openssh-server | grep "/init"

and on Red Hat-based systems using rpm:

rpm -ql openssh-server-4.3p2 | grep "/init"

Be aware that the top-level package used to install the service may not be the one that contains the control script: it could be provided by a dependency.

If you do not know the package name then you could try searching /etc/init.d and /etc/init for a likely-looking filename.

Optionally, validate the new configuration

Some services provide a means to validate the configuration before loading it. This is highly desirable when running a mission-critical server, because if an error is encountered while loading then you may be left with no service until it is fixed.

The method for requesting validation will depend on the software in question, if it is available at all. For Apache on Debian-based systems you can use the apache2ctl command:

apache2ctl -t

Forcibly reload the configuration

If the service command is available then use it to forcibly reload the configuration. For example, if you have determined that the service name is apache2:

service apache2 force-reload

Otherwise, invoke the init.d script directly:

/etc/init.d/apache2 force-reload

The meaning of force-reload is that the configuration should be reloaded without restarting the service if possible, but with a restart if necessary. It is preferable to reload or restart because:

Troubleshooting

The service cannot be stopped

If force-reload equates to restart then the control script will need to kill any running processes before starting new ones. Sometimes this fails, in which case you will need to identify and kill the running processes yourself.

Most likely the control script will have attempted a graceful termination using SIGTERM. It is worth trying that again, in case the script did not send the signal for some reason:

killall apache2

Be patient waiting for processes to exit, because some (such as Squid) can take tens of seconds. However if it is clear that SIGTERM has not worked then you can issue a SIGKILL with a clear conscience:

killall -KILL apache2

The service does not restart

This probably indicates an error in the configuration file. Alternative possibilities include:

A well-written init script should check that a process has died after sending it a SIGTERM, but some do not. If the service listens on a specific port number (as most do) or needs to exclusively lock files then failure to terminate the old instance will prevent a new instance from starting.

Even if the previous instance has stopped, if it has left a server socket in the TIME_WAIT state then it may still prevent a new instance from starting for a short period (typically 2 minutes on Linux). The condition occurs when the server terminates an active connection (gracefully or otherwise). Servers can be written to disregard TIME_WAIT, but not without risk. Some do this, some do not.

Alternatives

Reboot the machine

It should rarely be necessary to reboot a machine running GNU/Linux, and it certainly isn't necessary to perform the task described here. However there is one advantage to rebooting after a configuration change: it provides assurance that the changes you have made are persistent, and will not break unexpectedly when a reboot is eventually needed.

Signal the process directly

If a daemon supports reloaded without restarting then the conventional method for signalling this is to send a SIGHUP, for example:

kill -HUP 29964

Do not assume that SIGHUP necessarily has this meaning: in principle it could do anything. You should also exercise caution if there are several copies of the server process running. For example, sending SIGHUP to all copies of sshd would cause one of them to reload the configuration file and the others to terminate the active connections they were handling.

Tags: service