Apologies for the long delay.
We discussed this issue in several TC meetings without being able to
make
real progress.
After several rounds of discussions we came to the conclusion that the
reason why we can't make progress is that we always end up hitting the
wall
of "The Technical
Hi,
On Wed, Oct 17, 2018 at 09:47:57PM +0100, Simon McVittie wrote:
> However, it leaves the default as "fail hard", which I'm not convinced
> is the most appropriate thing for systems that lack an experienced
> sysadmin (which are the systems where defaults matter most, because an
>
On Tue, 09 Oct 2018 at 20:35:33 +0200, Wouter Verhelst wrote:
> According to "man invoke-rc.d", policy-rc.d can exit with exit state 106
> and provide a number of actions on stdout. These are then actions that
> invoke-rc.d must try in order "until one of them succeeds". As such, a
> policy-rc.d
I must stop writing emails when tired...
On Tue, Oct 09, 2018 at 08:35:33PM +0200, Wouter Verhelst wrote:
> On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> > - The policy-rc.d interface could be extended to allow it to signal a
> > "restart, but do not fail on error" kind of
On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> - The policy-rc.d interface could be extended to allow it to signal a
> "restart, but do not fail on error" kind of policy. This would work
> for the "we have thousands of desktops and don't care about a service
> failing to
> "Ian" == Ian Jackson writes:
Ian> * If the maintainer has no particular reason to diverge the
Ian> right answer is usually to fail the postinst with init systems
Ian> that do not provide service supervision; but to not fail the
Ian> postinst with ones that do. (I think
Wouter Verhelst writes ("Re: Bug#904558: What should happen when maintscripts
fail to restart a service"):
> Perhaps the error handler should also be configurable by policy-rc.d, as
> I hinted to before.
I think this is a key point. We do not have to make a single decision
wh
Hi Simon,
Thanks for your summary.
On Sun, Oct 07, 2018 at 11:49:09AM +0100, Simon McVittie wrote:
> Attempting to summarize what was said on this topic in the thread so
> far, and at the last technical committee meeting:
>
> It's perhaps important to note that we are not discussing ideal
Am 07.10.18 um 20:55 schrieb Michael Biebl:
> Am 07.10.18 um 20:46 schrieb Michael Biebl:
>> Let me add here, that a lot of sysv init scripts I looked at do not
>> actually return proper error codes in case the service fails to start.
>> Picking a random example, like anacron, I see for the start
Am 07.10.18 um 20:46 schrieb Michael Biebl:
> Let me add here, that a lot of sysv init scripts I looked at do not
> actually return proper error codes in case the service fails to start.
> Picking a random example, like anacron, I see for the start action:
>
> start-stop-daemon --start --exec
> * dh_installinit: defaults to "failure to (re)start is failure to
> configure", but can be overridden with --error-handler; some packages
> set the error handler to "true" (e.g. apache2, isc-dhcp) or to a custom
> shell function (e.g. krb5, samba).
> This is used for LSB init scripts,
> "Simon" == Simon McVittie writes:
Simon> the error path is most important were packages that provide a
Simon> system-level API to other packages, so their failures are
Simon> likely to cause other packages to fail to configure (such as
Simon> local DNS caches and
Attempting to summarize what was said on this topic in the thread so
far, and at the last technical committee meeting:
It's perhaps important to note that we are not discussing ideal situations
here: any time this conversation becomes relevant, something is already
wrong. We're aiming to
Someone asked for an example, here is one I've often seen when doing a
release upgrade on many webservers I administer: Apache will fail to
start. I don't recall if that currently causes Apache postinst to fail,
but if not, it really ought to continue.
Apache has a complicated config, and
On Sat, Sep 22, 2018 at 09:50:11AM +0200, Wouter Verhelst wrote:
> Nobody is arguing that if the init system or policy-rc.d block service
> starts, that then postinst should silently not start the daemon.
That should read:
Nobody is arguing that if the init system or policy-rc.d block service
Hi Tollef,
On Fri, Sep 21, 2018 at 09:53:13PM +0200, Tollef Fog Heen wrote:
> ]] Wouter Verhelst
>
> > On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
>
> [...]
>
> > > The API provided by a package being in the configured state is not
> > > whether the relevant daemon is
On Fri, Sep 21, 2018 at 10:07:31PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson
>
> > Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts
> > fail to restart a service"):
>
> [...]
>
> > > This means that failur
]] Ian Jackson
> Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts
> fail to restart a service"):
[...]
> > This means that failure to start a daemon should generally not cause the
> > postinst to fail.
>
> ... I disagree with tha
]] Wouter Verhelst
> On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
[...]
> > The API provided by a package being in the configured state is not
> > whether the relevant daemon is running or not; that is runtime and can
> > and will change many times while the package is in
Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended operation
Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson:
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I thin
On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson
>
> Hi,
>
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I think this is the core question. I largely agree with Ian
Stuart Prescott dijo [Wed, Sep 19, 2018 at 12:18:24PM +1000]:
> (...)
> That was perhaps also written before we started to realise that maintainer
> scripts are actually best avoided as they tend to be complicated, fragile,
> difficult to do right and make upgrades harder for the package
Ian Jackson wrote:
>> I personally think that it would make sense for the policy to at least
>> recommend what should happen with regards to maintainer scripts and
>> typical operations that are performed in them.
>
> There is already a section on error handling in scripts, which (IMO
>
]] Ian Jackson
Hi,
> There may be good reasons not to treat daemon startup failure as a
> postinst failure, but the argument above is not one of them.
I think this is the core question. I largely agree with Ian here that
having postinsts fail is not that big a deal if they can't make forward
Margarita Manterola writes ("Bug#904558: What should happen when maintscripts
fail to restart a service"):
> Sorry that it took so long to get back to this bug. The other bug took
> all the attention.
...
> If a postinst fails (for whatever reason), the package is left
Hi,
Sorry that it took so long to get back to this bug. The other bug took
all the attention.
On 2018-07-25 06:07, Sean Whitton wrote:
If postinst or one of the other scripts does a service restart and
the restart operation fails, should the postinst abort or should it
mask the
Hello,
Thank you for your reply.
On Thu 09 Aug 2018 at 09:19pm +0200, Tollef Fog Heen wrote:
> ]] Sean Whitton
>
>> The general question about which I am seeking advice: does the
>> T.C. think that Debian can be consistent on service (re)starts in
>> maintscripts, or is the best we can do to
]] Sean Whitton
> The general question about which I am seeking advice: does the
> T.C. think that Debian can be consistent on service (re)starts in
> maintscripts, or is the best we can do to leave it up to package
> maintainer discretion?
I think we can give advice on what the default should
Package: tech-ctte
X-debbugs-cc: debian-pol...@lists.debian.org
Control: block 780403 by -1
I hereby request advice from the Technical Committee on a decision that
I must take in my role as a Debian Policy delegate. To be completely
clear, I am not seeking a decision. I refer to the third power
30 matches
Mail list logo
