On Tue, Aug 05, 2008 at 12:44:12PM +0200, Petter Reinholdtsen wrote:

> As far as I am concerned, the boot/shutdown system in Debian do not
> need stop symlinks to kill daemons, as init.d/sendsigs do the same job
> quicker and better, and thus consider all packages doing it to be
> wasting resources. I would recommend severity normal, as this issue
> is just wasting resources, not breaking functionality.

This is definitely *not* true for a number of services - giving your
database server 5 seconds to flush all its state to disk before it's hard
terminated is not ok. So I hope you aren't really encouraging people to
file bugs on *all* packages that have [06] shutdown scripts, without
consideration for whether these daemons need to save state...

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

[Steve Langasek]
> This is definitely *not* true for a number of services - giving your
> database server 5 seconds to flush all its state to disk before it's
> hard terminated is not ok. So I hope you aren't really encouraging
> people to file bugs on *all* packages that have [06] shutdown
> scripts, without consideration for whether these daemons need to
> save state...

Nope, I am definitely not doing that. Only those that are happy
with a single SIGTERM during shutdown.

Also, note that sendsigs now (since Lenny) will wait for up to 10
seconds for processes to die after the SIGTERM before sending SIGKILL.
The period can be extended if it proves to be too short, but in most
cases I have seen, processes have died within 2-3 seconds.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Petter Reinholdtsen wrote:

> Also, note that sendsigs now (since Lenny) will wait for up to 10
> seconds for processes to die after the SIGTERM before sending SIGKILL.
> The period can be extended if it proves to be too short, but in most
> cases I have seen, processes have died within 2-3 seconds.

I still don't understand why a SIGTERM is needed. If proper cleanup is not
needed, why not just SIGKILL and be done with it? Is there a real reason?


--

Felipe Sateler


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Felipe Sateler <fsateler@gmail.com> writes:

> I still don't understand why a SIGTERM is needed. If proper cleanup
> is not needed, why not just SIGKILL and be done with it? Is there a
> real reason?

My understanding only:

It is preferable for processes to clean up after themselves, which is
the semantic of SIGTERM. Only those processes which were not able to
do so in a timely manner will be abruptly killed with SIGKILL.

--
“Quidquid latine dictum sit, altum viditur.� (“Whatever is |
` said in Latin, sounds profound.�) —anonymous |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

]] Ben Finney

| Felipe Sateler <fsateler@gmail.com> writes:
|
| > I still don't understand why a SIGTERM is needed. If proper cleanup
| > is not needed, why not just SIGKILL and be done with it? Is there a
| > real reason?
|
| My understanding only:
|
| It is preferable for processes to clean up after themselves, which is
| the semantic of SIGTERM. Only those processes which were not able to
| do so in a timely manner will be abruptly killed with SIGKILL.

But if you have cleanups to do, you should have a proper stop script (or
you have a race condition). (If it's just about removing shared memory
segments and such, there's no need to clean up -- the system is about to
go away anyway.)

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org