* Peter Samuelson <peter@p12n.org> [080705 02:37]:
>
> [Marvin Renich]
> > If the package does need to save state, don't enable the "quick halt"
> > option! The maintainer definitely ought to know this.
>
> Why are all of you talking as though sending SIGTERM were not the
> standard way to tell a process to save its state and exit gracefully?
> It's certainly the method I would use if I were writing a program that
> needed to do things at exit time. I thought everyone did it that way.

In addition to Steve's response, there is also the issue of ordering.
Some packages (by design or sysadmin configuration) require other
services to be running during their shutdown.

...Marvin


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

In article <20080705063643.GB24276@p12n.org> you wrote:
> Why are all of you talking as though sending SIGTERM were not the
> standard way to tell a process to save its state and exit gracefully?

Thats not the point. It is a quesion of sequence. When you get the killall5
sigterm, then everybody else also gets it. Especially maybe your file
service server. So you might not able to save.

Gruss
Bernd


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

* Bernd Eckenfels

| In article <20080705063643.GB24276@p12n.org> you wrote:
| > Why are all of you talking as though sending SIGTERM were not the
| > standard way to tell a process to save its state and exit gracefully?
|
| Thats not the point. It is a quesion of sequence. When you get the killall5
| sigterm, then everybody else also gets it. Especially maybe your file
| service server. So you might not able to save.

If the local admin introduces other dependencies than what can
reasonably be set as defaults, he should also make sure to adjust
dependency and stop-level headers in init scripts. If he fails to do
that, he might break his system, just like if he doesn't take care
when doing all other kinds of maintenance to the system.

We can give the admin reasonable tools to do his job, but we can't do
it for him, nor can we divine any setup that an admin might come up
with and which might confuse the tools we have provided.

--
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

James Westby wrote:
> On Tue, 2008-07-01 at 15:38 +0200, Frans Pop wrote:
>> I happened to see a similar bug filed against backuppc.
>>
>> How many of these bugs have been filed?
>> Are you aware of the Debian policy regarding mass bug filing [1]?
>
> I have filed two (from memory). I am aware of that policy.
>
>> IMO this is a subject that definitely should have been discussed on
>> d-devel _before_ the bugs were filed.
>
> It was discussed. What sort of resolution would you like before these
> bugs were filed?

OK. I don't not remember that. A pointer to that discussion would be
useful. You only included a link to a Ubuntu web page which is IMO not
directly relevant when proposing structural changes in Debian (or at
least: does not provide sufficient justification for proposing/applying
packaging changes in Debian).

> If you mean that discussion of a proposed MBF should have happened then
> I'm not sure that what I have done warrants that.

Reason I think at least some kind of consensus on d-devel should be
reached is that, although only two BRs have been filed now, a lot more
packages are affected. IMO this is something where packages should be
consistent which makes the change effectively a policy change.

> If someone was to collect all of the Ubuntu patches to do this and
> submit them at once then it obviously would. However, Ubuntu has only
> just changed to something that is acceptable to Debian and so most
> packages have not been updated yet.

Where was it determined that the current Ubuntu solution is acceptable and
desirable for Debian? Was it discussed whether or not such changes are
suitable to be applied at this stage of the Lenny release cycle?

Cheers,
FJP

On Mon, 2008-07-07 at 17:05 +0200, Frans Pop wrote:
> OK. I don't not remember that. A pointer to that discussion would be
> useful. You only included a link to a Ubuntu web page which is IMO not
> directly relevant when proposing structural changes in Debian (or at
> least: does not provide sufficient justification for proposing/applying
> packaging changes in Debian).

I also linked to the previous discussion on this mailing list. My
reading of that was that many people wanted the benefit that this
brings, but that the implementation wasn't right.

> Reason I think at least some kind of consensus on d-devel should be
> reached is that, although only two BRs have been filed now, a lot more
> packages are affected. IMO this is something where packages should be
> consistent which makes the change effectively a policy change.
>

I can see your point here, and perhaps I should have written to the list
to discuss it first.

> Where was it determined that the current Ubuntu solution is acceptable and
> desirable for Debian? Was it discussed whether or not such changes are
> suitable to be applied at this stage of the Lenny release cycle?

Perhaps I misspoke. I should have said that the current solution does
not suffer from the issues that made the previous solution unacceptable.

Therefore I'd like to ask a few questions:

1. Are there any objections to the approach that have not already
been raised in the thread?
2. Does anyone feel that the objections mean that this approach
should not be adopted?
3. Are these changes appropriate for this stage of the release cycle?

Thanks,

James



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

Hi,

I've been refraining from sending any patches on this subject since
this thread started. I'd like to start sending them again so that
both Debian and Ubuntu can benefit. However, I'm not sure whether
this thread has reached a resolution such that I can do so.

Please allow me to attempt to answer my own questions.

On Mon, 2008-07-07 at 16:29 +0100, James Westby wrote:
> Therefore I'd like to ask a few questions:
>
> 1. Are there any objections to the approach that have not already
> been raised in the thread?

It doesn't appear so.

> 2. Does anyone feel that the objections mean that this approach
> should not be adopted?

It doesn't appear so.

> 3. Are these changes appropriate for this stage of the release cycle?

Obviously not. I realise that any bugs I file now will have to sit
unfixed until lenny is released (ignoring experimental). Is that
going to be a problem? I hope that maintainers won't mind having
one extra bug with patch open on their package during a freeze.

I would post a dd-list of the packages affected, but I don't have
a complete list available to do so. I would obviously prefer to just
submit these patches individually (and allow others to do so), is
submitting the list up front a hard requirement? dev-ref requests
it, but isn't clear.

Thanks,

James


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

On Wed, Jul 30, 2008 at 12:13 AM, James Westby
<jw+debian@jameswestby.net> wrote:

> Obviously not. I realise that any bugs I file now will have to sit
> unfixed until lenny is released (ignoring experimental). Is that
> going to be a problem? I hope that maintainers won't mind having
> one extra bug with patch open on their package during a freeze.

I doubt this will be a problem, clue-bats should be applied otherwise.

> I would post a dd-list of the packages affected, but I don't have
> a complete list available to do so. I would obviously prefer to just
> submit these patches individually (and allow others to do so), is
> submitting the list up front a hard requirement? dev-ref requests
> it, but isn't clear.

If you don't yet have the full list of affected packages, providing
the current list and saying it is incomplete and further bugs will be
filed as daemons are audited should be fine.

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

On Wed, 2008-07-30 at 14:58 +0800, Paul Wise wrote:
> If you don't yet have the full list of affected packages, providing
> the current list and saying it is incomplete and further bugs will be
> filed as daemons are audited should be fine.

Hi,

Below is the current list that I was able to calculate. There
are also bugs filed on backuppc and system-tools-backends.

I may have missed some packages where the change has already
been made in Ubuntu, due to using a rather simple grep to
find the packages. There will also probably be extra
packages in the future as this scheme is widened.

Note that many of the packages below still need to be converted
to the new scheme, which will take a little bit of time, so
the bugs won't appear straight away.

Thanks,

James


Thomas Anders <tanders@users.sourceforge.net>
net-snmp (U)

Daniel Baumann <daniel@debian.org>
acct

CJ van den Berg <cj@vdbonline.com>
pulseaudio

Marco Bertorello <marco@bertorello.ns0.it>
powernowd

Fathi Boudra <fabo@debian.org>
kde-guidance (U)

Mark Brown <broonie@debian.org>
nis
nis (U)

Debian Cyrus SASL Team
<pkg-cyrus-sasl2-debian-devel@lists.alioth.debian.org>
cyrus-sasl2

Debian KDE Extras Team <pkg-kde-extras@lists.alioth.debian.org>
kde-guidance

Debian NTP Team <pkg-ntp-maintainers@lists.alioth.debian.org>
ntp

Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org>
destar

Randall Donald <rdonald@debian.org>
nvidia-kernel-common

Peter Eisentraut <petere@debian.org>
ntp (U)

Fabian Fagerholm <fabbe@debian.org>
cyrus-sasl2 (U)

Fetchmail Maintainers <pkg-fetchmail-maint@lists.alioth.debian.org>
fetchmail

Jochen Friedrich <jochen@scram.de>
net-snmp (U)

Bdale Garbee <bdale@gag.com>
ntp (U)

Hector Garcia <hector@debian.org>
fetchmail (U)

Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
resolvconf (U)

Filippo Giunchedi <filippo@debian.org>
pbbuttonsd (U)

Nico Golde <nion@debian.org>
fetchmail (U)

Guido Guenther <agx@sigxcpu.org>
smartmontools

Thomas Hood <jdthood@yahoo.co.uk>
resolvconf (U)

Alberto Gonzalez Iniesta <agi@inittab.org>
irda-utils

Aurelien Jarno <aurel32@debian.org>
lm-sensors-3

Simon Kelley <simon@thekelleys.org.uk>
dnsmasq

Torsten Landschoff <torsten@debian.org>
ddclient

Frank Lichtenheld <djpig@debian.org>
pbbuttonsd

Robert Luberda <robert@debian.org>
dictd

Dovecot Maintainers <jaldhar-dovecot@debian.org>
dovecot

Michael Meskes <meskes@debian.org>
acpid (U)
kde-guidance (U)

Noah Meyerhans <noahm@debian.org>
net-snmp (U)

Marco Nenciarini <mnencia@debian.org>
resolvconf (U)

Net-SNMP Packaging Team <pkg-net-snmp-devel@lists.alioth.debian.org>
net-snmp

Jaakko Niemi <liiwi@debian.org>
tftp-hpa

Alejandro Rios P. <alejandro.rios@avatar.com.co>
destar (U)

Mark Purcell <msp@debian.org>
destar (U)
kde-guidance (U)

Petter Reinholdtsen <pere@debian.org>
resolvconf (U)

resolvconf maintainers <resolvconf-devel@lists.alioth.debian.org>
resolvconf

Santiago Ruano Rincón <santiago@debian.org>
destar (U)

Marco Rodrigues <gothicx@sapo.pt>
ddclient (U)

Kurt Roeckx <kurt@roeckx.be>
ntp (U)

Anibal Monsalve Salazar <anibal@debian.org>
acpid

Roberto C. Sanchez <roberto@connexer.com>
cyrus-sasl2 (U)

Martin Schulze <joey@debian.org>
sysklogd

Sjoerd Simons <sjoerd@debian.org>
pulseaudio (U)

Paul Slootman <paul@debian.org>
rsync

Miquel van Smoorenburg <miquels@cistron.nl>
nis (U)

Fabio Tranchitella <kobold@debian.org>
dovecot (U)

Matej Vela <vela@debian.org>
vsftpd

Jaldhar H. Vyas <jaldhar@debian.org>
dovecot (U)

Alexander Wirt <formorer@debian.org>
keepalived


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

[James Westby]
> Below is the current list that I was able to calculate. There are
> also bugs filed on backuppc and system-tools-backends.

Not too bad, it seem.

Just to chip in my view on this, as one of the sysvinit package
maintainers. I believe dropping shutdown symlinks in runlevel 0 and 6
for scripts that only kill the daemon is a good idea, and have
recommended on several occations when I submitted BTS reports about
dependency based boot sequencing.

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.

It would be great if we could speed up shutdown a bit more.

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

[Hai Zaar]
> We can add even more flexibility: You may leave today's scripts as
> they are, and add "skippable" flag somewhere around LSB headers or
> /etc/default/<name>.
> Then if system administrator will have some weired situation where
> he should like to perform explicit shutdown for particular service -
> it can just unset "skippable" flag for that service.

This is already possible using the "flag" represented by the symlinks
in /etc/rcX.d/. If the package maintainer do not want the script to
run in runlevel 0 and 6, the symlinks will be missing. If the
sysadmin want to run the script anyway, the symlinks can be added.
The package system will keep the symlinks and the sysadmin should get
what he want.

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