4

I did sudo service ... stop before shutting down the machine remotely, over SSH, but then I realized I didn't know if stop is synchronous or not and I wondered if I was not too fast to shut down the Ubuntu machine.

So are my fears based on a wrong hunch or not ?

Edit: My service is a personal one, it receives listens to stuff from a port and writes things now and then to a database. I fear that things don't have the time to be flushed if the service is stopped abruptly. stop takes care of flushing things but given the time it could take...

Joseph R.
  • 39,549
Thomas
  • 893
  • You need to specify what service you are interested in and what you "fear" would happen from abrupt (or incomplete) stopping. In general most services will behave just fine if stopped rapidly by halt, poweroff, or similar. – msw Sep 04 '13 at 09:23
  • See edit : that's why I want to know if the stop is asynchronous or synchronous – Thomas Sep 04 '13 at 09:41
  • Short answer: since the service scripts are entirely at the whim of the author, it depends on what you stopped. – Chris Down Sep 04 '13 at 11:49
  • Short short answer from @Gilles, stop is synchronous, and it doesn't depend on what's inside the stop function of the service, as long as it takes just a few seconds to stop. – Thomas Sep 06 '13 at 08:44
  • @Thomas It doesn't have to be synchronous, it depends on how the script is written, and your init system. – Chris Down Sep 10 '13 at 08:16

2 Answers2

3

Ensure that your application

  1. logs its proper shutdown to syslog, see man 3 syslog for details
  2. handles SIGTERM by writing all it needs to the database, closing the connection and exiting; see man 2 sigaction for detail
  3. has a working stop handler in /etc/init.d; see man init and man stopping

and then you won't have to guess about whether your application stops properly, you'll know.

msw
  • 10,593
0

It depends of how your service is stopped. Only you knows: the service start and stop methods are things that you should document for users of your service, and ideally provide.

If your service is stopped by sending a signal to it by calling kill from a shell script, this is asynchronous. The kill command or system call sends a signal to a process and returns immediately. There is no mechanism for the process to call back to notify that it has processed the signal to its satisfaction. So you need to find another method to signal that you are done.

Many methods are possible, such as having the service create or remove a file and the control script watch for changes to that file. However they tend to be awkward. Sending a signal from an unrelated process is not a very good method if you need feedback when the service is finished.

If your service is stopped via a stop directive in an Upstart service description, Upstart sends a signal to the process. Upstarts then waits for a few seconds for the process to stop. Because Upstart is the parent of the process, it receives a notification from the kernel (a SIGCLD signal) when the process exits. This only works well when the process doesn't fork to put itself in the background; Upstart service descriptions normally call daemons with an option telling them not to fork (e.g. ssh -D).

Advanced services have a throttling command. When you call the throttling command, they stop accepting new connections. When all pending connections are closed, the service sends a positive reply to the throttling command and then exits. The communication method is typically a Unix or IP socket.

Gilles 'SO- stop being evil'
  • 829,060
  • "Upstarts then waits for a few seconds for the process to stop." I'm not sure this is true. My experience is that the stop command returns immediately. You can test this with something like stop <name>; ps -efww | grep <name>. You'll often see that the service is still running. – Mike Conigliaro Feb 14 '14 at 23:12
  • @MikeConigliaro I think Upstart waits for the ancestor process, but doesn't detect child processes that are still running (and can't, really, not reliably enough not to cause collateral damage such as killing SSH sessions when restarting the server). – Gilles 'SO- stop being evil' Feb 15 '14 at 22:40