What is the difference between "service restart" and "service reload"

Question

I'm trying to understand the difference between service restart [someservice] and service reload [someservice]. I understand that restart restarts the service whereas reload reloads the configuration. But I don't understand the practical implications of this well enough to determine which I should use in a given context.

An example: most guides I've read for setting up PostgreSQL say that, once I've edited postgresql.conf and pg_hba.conf to allow remote connections, I should run:

sudo service postgresql restart

However, if I were to guess which to use based on the description above, I would choose reload.

In case it matters, I'm on Ubuntu 11.10, though I'm hoping for an as generally applicable explanation as possible.

Answer 1

• restart = stop + start
• reload = remain running + re-read configuration files.

Answer 2

What you said is correct, reload tells the service to reload its configuration files. That means it should be sufficient to reload the configuration; however there may be certain services that "don't follow the rule" or that won't reload config files. Due to this you're probably safer with restart. I personally do not use postgresql, so I don't know.

Answer 3

Not all services support reload. For those that do, it is usually preferable to restarting (i.e. reloading causes less or no downtime).

The Debian Policy Manual specifies that every /etc/init.d/ script should support a force-reload action, which means reload if the service supports it, and restart if the service doesn't support reloading.

I'm not sure how that translates into the modern Ubuntu upstart world.

Answer 4

To expand عبد النور التومي answer with my experience with systemd.

In systemd whenever a process is started it is run within systemd context, most clear example of this is with the environment variables defined in its unit file.

So when you send a systemctl reload [someservice] signal it sends a signal to the service to reload itself gracefully if it is supported. If not, the process will simply ignore the signal. This is configurable though.

What do I mean with gracefully? to start new workers with the new configuration or code and stop the old workers as they finish serving current requests if any.

And if you make systemctl restart [someservice] it will tell systemctl to tell the service to stop, destroy the current systemd context, create a new one and run the service again. This makes sense for example to reload environment variables in a systemd context or if a reload is not supported.

Hope this clarifies a little and if I'm wrong in something please let me know.

Answer 5

Signal detail may be important for reload.
Most of times it is all about sending a proper signal (SIGHUP) to service process. If the underlying application has some kind of 'live configuration re-apply' strategy, then most probably there should be a line starting with "ExecReload=" in the service unit file. Which means reload is optional and you need to check if the application implements reload: (docker i.e.)

cat $(echo $(systemctl show -p FragmentPath docker) | cut -d "=" -f 2)

Restart is just stop-start. Systemd only needs to know proper "ExecStart" command to start.

Answer 6

currently if a service needs kicking (e.g. a config file changed) you can notify the service, but this leads to a restart. It would be nice if a reload was done if the service was already running (although I suppose there are bound to be some services which require restarts for some files, reloads for others).

The most complex example I can think of is something like Apache. Normally you can just ask it to reload, however sometimes you need to request a restart instead (if you add/remove modules for example).

Answer 7

postgres is a good example for big differences between reload and restart, because the later has to disconnect all database-clients.

when the connections should not rollback, you can stop the service without a "--force" at first by using pg_ctlcluster.

in /etc/postgres/{version}/{dbname}/postgresql.conf and at http://www.postgresql.org/docs/manuals/ every parameter has a remark like "This parameter can only be set at server start."