Hi Colin,
Le mercredi 01 janvier 2014 à 17:17 +, Colin Watson a écrit :
Basically, systemd would be more compelling to me if it tried to do
less. I don't expect to persuade systemd advocates of this, as I think
it amounts to different basic views of the world, but the basic
Le mardi 31 décembre 2013 à 19:01 -0800, Steve Langasek a écrit :
It's not true that it's unrelated. In v205, logind hands off the cgroup
heirarchy creation to PID 1, precisely because it's preparing for the
anticipated future kernel requirement of a single cgroup writer.
This change would
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
On Wed, 2014-01-01 at 17:17 +, Colin Watson wrote:
On Wed, Jan 01, 2014 at 05:52:03PM +0100, Ansgar Burchardt wrote:
On the other hand even when using upstart as an init replacement, we'll
continue to use large chunks of
On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
and I think it'd be a shame if we ended up losing or demotivating a
good bunch of good developers again.
Pretty much every time the CTTE makes a ruling, someone is going to be
Colin Watson cjwat...@debian.org writes:
On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
and I think it'd be a shame if we ended up losing or demotivating a
good bunch of good developers again.
Pretty much every time the CTTE
On Thu, Jan 02, 2014 at 01:09:27PM +, Ian Jackson wrote:
Colin Watson writes (Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]):
Is there any useful way we could take a reasonably quick non-binding
straw poll of developers? Sort of an if we voted
Colin Watson writes (Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]):
On Thu, Jan 02, 2014 at 01:09:27PM +, Ian Jackson wrote:
Obviously that would be embarrassing for us and substantially damage
our credibility. But I don't think it's at all
On Thu, 02 Jan 2014, Ian Jackson wrote:
And, despite the fact that the decision has become very politicised
(to some extent along the lines of preexisting camps of strongly
disagreeing contributors), I think it is primarily a technical
decision.
The line of thought that you have been
So we know where Colin, Steve, Russ and I stand on the main question.
If we want to make a decision soon we need to start to thrash out the
details so that we have something concrete to vote on.
It would be helpful to know how far along the other TC members are.
So:
Andreas, Bdale, Don, Keith:
On Thu, 2014-01-02 at 12:37 +, Colin Watson wrote:
On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
and I think it'd be a shame if we ended up losing or demotivating a
good bunch of good developers again.
Pretty much every
Raphael Hertzog writes (Re: CTTE and Developer Buy-in [Re: Bug#727708: init
system other points, and conclusion]):
I do. I know at least one person who expressed his intent to leave Debian
if Debian wasn't able to make the choice of systemd. So if one is ready to
resign, there will likely be
Ansgar Burchardt ans...@debian.org writes:
Sometimes I also wonder if a GR might be a better way to deal with the
decision as this feels more and more like an political or opinion
decision rather then a technical decision to me as tech-ctte members
have found both upstart and systemd to be
On Thu, 2014-01-02 at 12:31 +, Colin Watson wrote:
On Wed, Jan 01, 2014 at 08:15:46PM +0200, Uoti Urpala wrote:
You can simply not install any of these additional services if you don't
want them. This is completely trivial to do.
It is indeed technically trivial, but I invite you to
(Long time listener, first time caller - so apologies if I'm doing this wrong.)
Russ Allbery writes (Bug#727708: init system other points, and conclusion):
3.1. Ecosystem Reality Check
...
Therefore, I believe the burden of proof is on upstart to show that it is
a clearly superior init system
Ian Jackson ijack...@chiark.greenend.org.uk writes:
And, despite the fact that the decision has become very politicised (to
some extent along the lines of preexisting camps of strongly disagreeing
contributors), I think it is primarily a technical decision.
I think this is a remarkable
Russ Allbery writes (Bug#727708: CTTE and Developer Buy-in [Re: Bug#727708:
init system other points, and conclusion]):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I don't think any of the TC are going to propose (b). Perhaps we
should put (b) on the TC ballot for form's sake; I
]] Colin Watson
Perhaps this is the fundamental disagreement. I do not necessarily
consider compatibility as an end in itself. Where Debian is already
better than other distributions, we should remain better, not stick to a
lowest common denominator for the sake of compatibility.
I think
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Based on the responses to the recurring flamewars on debian-devel, I
think the majority of contributors are happy not to have to wrestle
with this decision and would prefer to leave it to us.
Agreed.
Perhaps we
should put (b) on the TC
I wanted to lift this out of the thread it was buried in and see if I'm
understanding it correctly, since if I am, it seems like a significant
issue.
Cameron Norman camerontnor...@gmail.com writes:
I think you raise a lot of good points in this email, but here you are
saying something which
Sjoerd Simons sjo...@debian.org writes:
While i don't have a good answer for your question, i did trigger me to
have a look at popcon to see what that told me in terms of popularity of
systemd vs. upstart.
Thank you!
Bdale
pgpPoSk59R79j.pgp
Description: PGP signature
On Thu, Jan 02, 2014 at 02:39:15PM +0100, Sjoerd Simons wrote:
While i don't have a good answer for your question, i did trigger me to
have a look at popcon to see what that told me in terms of popularity of
systemd vs. upstart. Unfortunately systemd can be pulled in quite easily
via
Josselin Mouette j...@debian.org writes:
It shouldn’t come as a surprise that it is hard for developers to
respect the TC’s decisions when we see disrespectful sentences like the
one above from some of its members.
I agree.
We are of course each entitled to hold opinions about such things,
On Thu, Jan 2, 2014 at 8:35 AM, Russ Allbery r...@debian.org wrote:
I wanted to lift this out of the thread it was buried in and see if I'm
understanding it correctly, since if I am, it seems like a significant
issue.
Cameron Norman camerontnor...@gmail.com writes:
I think you raise a lot
As I mentioned in some of my previous notes, I was unable to evaluate
OpenRC in a meaningful way during my general experiments for a few
reasons. My impression was formed based on previous discussion and what
documentation I could find, which was fairly minimal.
Thomas Goirand sent me
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Andreas, Bdale, Don, Keith: please let us know what you're thinking,
and what more information/discussion would be useful.
Right. I've meant to post something before now, but after returning
home from a family road trip over the holidays, I
Bdale Garbee writes (Bug#727708: init system discussion status):
[stuff]
Thanks for posting your views.
You'll have seen Russ's comments on the details and loose ends as I
call them. Russ and I were mostly agreed on these points.
I have written a draft resolution from my own point of view and
Russ Allbery r...@debian.org writes:
This message is about a transition plan for an init system replacement and
about how to handle portability to our non-Linux ports. I'm keeping the
same subject as Ian's message on the same basic topics and attaching it to
the same thread, but this is more
On Mon, Dec 30, 2013 at 02:03:22 -0800, Steve Langasek wrote:
The upstart session init runs as the user, not as root.
Note that a session init can run as root (sudo init --user) but yes,
conventionally they are run as non-priv users.
I'm not sure if
upstart as a user session has any
On Thu, 02 Jan 2014, Russ Allbery wrote:
Ian Jackson ijack...@chiark.greenend.org.uk writes:
And, despite the fact that the decision has become very politicised (to
some extent along the lines of preexisting camps of strongly disagreeing
contributors), I think it is primarily a technical
Steve Langasek vor...@debian.org writes:
However, I think this gets to the heart of why upstart upstream has avoided
ever recommending the use of socket-based activation. There are some fairly
fundamental problems that basically halted development of socket-based
activation in upstart (beyond
Nikolaus Rath writes (Bug#727708: loose ends for init system decision):
I think there is one additional questions that will probably need to be
decided by the tc but hasn't really been discussed yet:
Will packages that explicity depend on a (non-default) init system be
allowed in Debian?
My
Ian Jackson writes (Re: Bug#727708: init system discussion status):
I have written a draft resolution from my own point of view and
checked it into the tech-ctte git repo. Perhaps some of it is useful.
Ansgar commented a bit on it on IRC. I guess I should post it.
Here's my draft.
Those
Nikolaus Rath writes (Re: Bug#727708: loose ends for init system decision):
For example, a hypothetical future program to interactively adjust
program cgroups cannot be sysvinit compatible in any meaningful sense,
because it does not need to be supervised, started, or stopped. However,
this
On 01/02/2014 10:20 AM, Ian Jackson wrote:
Nikolaus Rath writes (Bug#727708: loose ends for init system decision):
I think there is one additional questions that will probably need to be
decided by the tc but hasn't really been discussed yet:
Will packages that explicity depend on a
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Ian Jackson writes (Re: Bug#727708: init system discussion status):
I have written a draft resolution from my own point of view and
checked it into the tech-ctte git repo. Perhaps some of it is useful.
Cameron Norman writes (Re: Bug#727708: init system discussion status):
On Thu, Jan 2, 2014 at 10:16 AM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
...
| 9. [ Policy should provide non-binding suggestions to Debian
|contributors who are converting daemons to upstart and/or
On 01/02/2014 10:30 AM, Ian Jackson wrote:
Nikolaus Rath writes (Re: Bug#727708: loose ends for init system decision):
For example, a hypothetical future program to interactively adjust
program cgroups cannot be sysvinit compatible in any meaningful sense,
because it does not need to be
Cameron Norman camerontnor...@gmail.com writes:
Should it not be added that raise(SIGSTOP) should only be used with a
command line option (like --debian-Z) to ensure that the daemon does not
hang on sysv or systemd?
No, because see Colin's point that Debian developers may be doing the
Russ Allbery writes (Bug#727708: init system discussion status):
Cameron Norman camerontnor...@gmail.com writes:
Should it not be added that raise(SIGSTOP) should only be used with a
command line option (like --debian-Z) to ensure that the daemon does not
hang on sysv or systemd?
No,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I think it would be reasonable to state that the raise(SIGSTOP)
integration should be done with a new command line option OR a new
environment variable; ie that the daemon should not be changed to
raise(SIGSTOP) by default.
Agreed.
I
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ian Jackson writes (Re: Bug#727708: init system discussion status):
I have written a draft resolution from my own point of view and checked
it into the tech-ctte git repo. Perhaps some of it is useful. Ansgar
commented a bit on it on IRC.
Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
I would hope that we can standardise on a single API to the system's
single cgroup writer.
I have already explained why this is not going to happen. The cgroups
API in systemd is already part of the core systemd interface and
Russ Allbery writes (Bug#727708: init system discussion status):
Thank you very much for writing this. (And, in general, thank you for
often taking the initiative in producing drafts. It's something that I
find difficult, and I really appreciate your work on it.)
Thanks. I agree with much
On Thu, Jan 2, 2014 at 11:46 AM, Josselin Mouette j...@debian.org wrote:
Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit :
I would hope that we can standardise on a single API to the system's
single cgroup writer.
I have already explained why this is not going to happen. The
]] Ian Jackson
I think it would be reasonable to state that the raise(SIGSTOP)
integration should be done with a new command line option OR a new
environment variable; ie that the daemon should not be changed to
raise(SIGSTOP) by default.
I don't see why you think that doing so because a
]] Ian Jackson
Nikolaus Rath writes (Bug#727708: loose ends for init system decision):
I think there is one additional questions that will probably need to be
decided by the tc but hasn't really been discussed yet:
Will packages that explicity depend on a (non-default) init system be
Tollef Fog Heen tfh...@err.no writes:
]] Ian Jackson
I think it would be reasonable to state that the raise(SIGSTOP)
integration should be done with a new command line option OR a new
environment variable; ie that the daemon should not be changed to
raise(SIGSTOP) by default.
I don't see
Tollef Fog Heen writes (Bug#727708: loose ends for init system decision):
Ian Jackson:
So, firstly, I would say that all packages must, in jessie at least,
continue to support sysvinit. Russ (from the other side of the
upstart/systemd fence) agrees. Failure to support sysvinit would be
On Thu, Jan 02, 2014 at 05:51:11PM +0100, Tollef Fog Heen wrote:
In addition to the popcon numbers referenced from Sjoerd, we have the
numbers from Michael's systemd survey in May 2013. The numbers there
were 35%/30%/33% for yes/dunno/no for systemd as default init when only
counting
| 8. Policy rules for support for init systems must:
|
|(a) Specify the use of a non-forking startup protocol (for
|upstart and systemd),
I'm not sure about upstart, but systemd is perfectly happy with
daemons which double fork (Type=forking in systemd parlance).
It is mildly
Zbigniew Jędrzejewski-Szmek writes (Bug#727708: requirement of non-forking
startup protocol):
| 8. Policy rules for support for init systems must:
|
|(a) Specify the use of a non-forking startup protocol (for
|upstart and systemd),
[ Replying to this thread after a large glass
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
| 8. Policy rules for support for init systems must:
|
|(a) Specify the use of a non-forking startup protocol (for
|upstart and systemd),
I'm not sure about upstart, but systemd is perfectly happy with daemons
which double
Russ Allbery writes (Bug#727708: requirement of non-forking startup protocol):
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
I think this should be changed to:
| 8. Policy rules for support for init systems must:
|
|(a) Encourage the use of a non-forking startup protocol (for
On Thu, Jan 02, 2014 at 09:50:58AM -0700, Bdale Garbee wrote:
Josselin Mouette j...@debian.org writes:
It shouldn’t come as a surprise that it is hard for developers to
respect the TC’s decisions when we see disrespectful sentences like the
one above from some of its members.
I agree.
On Thu, Jan 02, 2014 at 10:04:12PM +, Ian Jackson wrote:
Zbigniew Jędrzejewski-Szmek writes (Bug#727708: requirement of non-forking
startup protocol):
| 8. Policy rules for support for init systems must:
|
|(a) Specify the use of a non-forking startup protocol (for
|
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Russ Allbery writes:
Yeah, this is a good point. Since systemd uses the daemon-written PID
file for tracking forking daemons, it doesn't have the same issues as
the upstart expect fork or expect daemon protocols. Obviously, an
external
Le jeudi 02 janvier 2014 à 14:27 -0800, Steve Langasek a écrit :
For several years the GNOME Team ignored section 9.7 of Policy, concerning
integration with the MIME handling system. They did this in favor of
implementing the related freedesktop.org on the grounds that the fd.o
standard is
Yeah, most daemons that write external PID files have issues with external
PID files left from other running instances of the same daemon. (I assume
that's what you're talking about.) It's probably possible to avoid that
with judicious use of file locking, but that's not common and is more
On Mon, Dec 30, 2013 at 09:52:04PM -0800, Russ Allbery wrote:
Steve Langasek vor...@debian.org writes:
Upstart (as implemented in Ubuntu) restores this guarantee (with
provisions for failsafe booting in the case of a wrong network config),
and it takes advantage of upstart's capability of
To wrap up this subthread, I want to state clearly for the record that the
answers that have been given here have addressed my concerns about the
raciness of systemd socket activation. It appears that the state of the art
is rather substantially improved since the last time I had looked at
Processing control commands:
tag -1 - patch
Bug #670170 [apparmor] apparmor: should load profiles before networking is setup
Removed tag(s) patch.
block -1 by 727708
Bug #670170 [apparmor] apparmor: should load profiles before networking is setup
670170 was not blocked by any bugs.
670170 was
Hi,
first, thank you for describing this problem in details.
I have never met it while using systemd on Debian Wheezy and sid for
18 months. Anyhow, with your indications at hand, I realize that my
use cases probably fall into the category that does not expose
this problem.
Steve Langasek wrote
62 matches
Mail list logo
