[Stefano Zacchiroli]
> If you are ready to monitor the issue closely, I don't see any
> problem in switching the default now in unstable, see how it goes,
> and then decide later on if revert back to the current default in
> Squeeze time.
The switch to parallel booting was done 2010-05-14 in unst
On Sun, 2010-05-16 at 14:18:57 +, Clint Adams wrote:
> On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote:
> > > Was this request ever actually made to the kfreebsd porters? I'm not sure
> > > that it was, in which case it's rather unfair to say that they've had
> > > enough
On Monday 10 May 2010 09:24:59 Steve Langasek wrote:
> And you don't have to use an initramfs; the same result could be achieved
> with a shim init on the root filesystem that does nothing but set up the
> SELinux context correctly and then exec upstart.
That's what I did years ago when we first s
On Sunday 16 May 2010 03:35:09 Steve Langasek wrote:
> Given the difference in how kernels vs. init daemons are usually
> administered as part of a system, I think the runtime impact of supporting
> multiple LSMs in init is much more significant than supporting multiple
> LSMs in the kernel. I don
On Sun, May 09, 2010 at 13:27:08 +0200, Marc Haber wrote:
> On Sat, 8 May 2010 11:47:40 +0200, Julien Cristau
> wrote:
> >As far as I'm concerned, "faster boot" is irrelevant. Using an init
> >daemon that actually does its job of supervising services, and lets us
> >get rid of most of the stupidi
On Mon, May 17, 2010 at 03:06:10PM +0100, Scott James Remnant wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10
> >
> This pretty much proves my point. I was never sent these patches,
> instead Debian kept them to itself and never attempted to get them
> upstream.
Well, we ca
> > I have never rejected any SELinux patches for Upstart; I have simply
> > never been *sent* any.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543420#10
>
This pretty much proves my point. I was never sent these patches,
instead Debian kept them to itself and never attempted to get the
On Mon, May 17, 2010 at 13:04:17 (CEST), Marc Haber wrote:
> On Fri, 14 May 2010 11:30:17 +0200, Scott James Remnant
> wrote:
>>> What is so bad about init scripts? Where am I supposed to put my init
>>> script magic[1] in an upstart scenario?
>>>
>>Upstart job configs go in /etc/init
>
> And I
On Fri, 14 May 2010 11:30:17 +0200, Scott James Remnant
wrote:
>> What is so bad about init scripts? Where am I supposed to put my init
>> script magic[1] in an upstart scenario?
>>
>Upstart job configs go in /etc/init
And I can do arbitrary things there, just as with an init script?
Greetings
On 17/05/10 00:06, Petter Reinholdtsen wrote:
[Felipe Sateler]
Here I get worse results for concurrency than non-concurrent:
CONCURRENCY=none: 51s
CONCURRENCY=makefile: 59s
CONCURRENCY=none + readahead: 37s
CONCURRENCY=makefile + readahead:
[Felipe Sateler]
> Here I get worse results for concurrency than non-concurrent:
>
> CONCURRENCY=none: 51s
> CONCURRENCY=makefile: 59s
> CONCURRENCY=none + readahead: 37s
> CONCURRENCY=makefile + readahead: 43s
This is not the way it should be, and
On 09/05/10 11:54, Eduard Bloch wrote:
#include
* Cesare Leonardi [Sun, May 09 2010, 12:26:36PM]:
Here what i've measured, from the Grub start to the Gdm prompt, in
either case starting from a completely power off machine:
Without concurrency: 33 sec.
With concurrency (try 1): 29 sec.
With conc
On Sat, May 15, 2010 at 10:57:56PM +0200, Petter Reinholdtsen wrote:
> > Was this request ever actually made to the kfreebsd porters? I'm not sure
> > that it was, in which case it's rather unfair to say that they've had enough
> > time when they were never informed this was a pressing issue.
>
>
On Fri, May 14 2010, Scott James Remnant wrote:
>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that has to be audited. There have
>> been patches proposed, and semi-reject
[Steve Langasek]
> Was this request ever actually made to the kfreebsd porters? I'm not sure
> that it was, in which case it's rather unfair to say that they've had enough
> time when they were never informed this was a pressing issue.
One request was done last summer, see
http://lists.debian.or
On Sun, May 09, 2010 at 06:09:10PM -0700, Manoj Srivastava wrote:
> > In speaking with upstart upstream, I understand that the argument against
> > linking to libselinux is that, as the kernel is neutral wrt the choice of
> > LSM, the init process should be also. Linking it against libselinux woul
On Sun, May 09, 2010 at 03:10:15AM +0200, Marco d'Itri wrote:
> On May 07, Julien Cristau wrote:
> > > - a decision to drop kfreebsd as a release architecture
> > Since 1 and 2 aren't happening, I think we should consider going with
> > the third option.
> Me too, I believe that the people inter
On Wed, May 12, 2010 at 09:59:59PM +0200, Petter Reinholdtsen wrote:
>
> [Cesare Leonardi]
> > If that helps, reading this thread i've set the previous variable in
> > my notebook (Sid with Gnome environment). I can see no problem but the
> > speed improvement is really small.
>
> Great to see mo
> It is still on the wishlist, but the needed pieces are not ready, so
> it seem unlikely to happen this late in the release process. At the
> moment, I believe it will happen shortly after Squeeze is released, if
> the needed pieces are ready by then.
>
I will be at DebConf all week.
I'll be th
> What is so bad about init scripts? Where am I supposed to put my init
> script magic[1] in an upstart scenario?
>
Upstart job configs go in /etc/init
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a d
> One of my concerns about upstart is that systems that want to
> use SELinux and upstart _have_ to also use an initramfs, which is yet
> another component of the system that has to be audited. There have
> been patches proposed, and semi-rejected b the upstart folks, who are
> of the opinions tha
On 7 May 2010 10:33, Paul Wise wrote:
> On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow
> wrote:
>> Stefano Zacchiroli writes:
>>> The init.d world has changed quite a bit in recent years and might
>>> change even more in the next, it is possible that for Squeeze+1 we'll
>>> want to be els
[Cesare Leonardi]
> If that helps, reading this thread i've set the previous variable in
> my notebook (Sid with Gnome environment). I can see no problem but the
> speed improvement is really small.
Great to see more test results. :)
> Here what i've measured, from the Grub start to the Gdm prom
On 10/05/2010 19:45, Raphael Geissert wrote:
> Marc Haber wrote:
>> I would like to ask the maintainer to first do his job _before_
>> forcing the new mechanism on all new users. If it isn't documented, it
>> ain't fit for Debian stable, especially as a default.
>>
>
> /usr/share/doc/insserv/READM
Hi,
Eduard Bloch wrote:
> First, it was readahead-fedora. Second, I followed that README now and
> updated readahead collection. Now they take both about 29 seconds, so I
> don't win anything with readahead.
That's definitely a bug, please file it (don't forget to include a bootchart
of both cas
#include
* Raphael Geissert [Sun, May 09 2010, 01:19:31PM]:
> Eduard Bloch wrote:
> > with concurency: 30s
> > with concurency and without readahead: 28s
>
> Interesting, a regression. Is that readahead from readahead-fedora?
>
> Were the 30 seconds measured by following the instructions from
>
Marc Haber wrote:
> I would like to ask the maintainer to first do his job _before_
> forcing the new mechanism on all new users. If it isn't documented, it
> ain't fit for Debian stable, especially as a default.
>
/usr/share/doc/insserv/README.Debian
...
--
Raphael Geissert - Debian Developer
On Mon, May 10, 2010 at 03:54:19PM +0200, Marc Haber wrote:
> >Thanks for the pointer. I've just submitted a patch for #576788 that
> >adds a pointer to that file from /etc/init.d/README.
>
> I would expect this in the defaults/rcS file as well, which is the
> place where I'd look.
Agreed, and wh
On Mon, 10 May 2010 13:02:51 +0200, Stefano Zacchiroli
wrote:
>On Sun, May 09, 2010 at 04:10:58PM +0300, Eugene V. Lyubimkin wrote:
>> >According to <4be43663.6000...@free.fr> and #576788, it is not.
>> >But I'm sure Petter welcome patches on this.
>> FWIW, it appears to be documented in README.De
On Sun, 9 May 2010 14:58:51 +0200, Stefano Zacchiroli
wrote:
>On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
>> > CONCURRENCY=makefile
>> Where is this documented?
>
>According to <4be43663.6000...@free.fr> and #576788, it is not.
>But I'm sure Petter welcome patches on this.
I woul
On Sun, May 09, 2010 at 04:10:58PM +0300, Eugene V. Lyubimkin wrote:
> >According to <4be43663.6000...@free.fr> and #576788, it is not.
> >But I'm sure Petter welcome patches on this.
> FWIW, it appears to be documented in README.Debian in the insserv package.
Thanks for the pointer. I've just sub
On Sun, May 09 2010, Steve Langasek wrote:
> On Sun, May 09, 2010 at 02:45:39PM -0700, Manoj Srivastava wrote:
>> One of my concerns about upstart is that systems that want to
>> use SELinux and upstart _have_ to also use an initramfs, which is yet
>> another component of the system that
On Sun, May 09, 2010 at 02:45:39PM -0700, Manoj Srivastava wrote:
> One of my concerns about upstart is that systems that want to
> use SELinux and upstart _have_ to also use an initramfs, which is yet
> another component of the system that has to be audited. There have
> been patches p
On Sat, May 08 2010, Marco d'Itri wrote:
> On May 07, Julien Cristau wrote:
>
>> > - a decision to drop kfreebsd as a release architecture
>> Since 1 and 2 aren't happening, I think we should consider going with
>> the third option.
> Me too, I believe that the people interested in kfreebsd-* ha
Eduard Bloch wrote:
> with concurency: 30s
> with concurency and without readahead: 28s
Interesting, a regression. Is that readahead from readahead-fedora?
Were the 30 seconds measured by following the instructions from
/usr/share/doc/readahead-fedora/README.bootchart ?
Cheers,
--
Raphael Geiss
#include
* Cesare Leonardi [Sun, May 09 2010, 12:26:36PM]:
> Here what i've measured, from the Grub start to the Gdm prompt, in
> either case starting from a completely power off machine:
> Without concurrency: 33 sec.
> With concurrency (try 1): 29 sec.
> With concurrency (try 2): 31 sec.
Sim
]] Stefano Zacchiroli
| I've just read a few days ago the design document of systemd; AFAIU it
| requires anyhow patching various daemons, no matter how trivial the
| patches are.
No, it doesn't require it, but it allows it. Cutting and pasting from
Lennart's blog post:
An ideal daemon for u
On Sun, May 09, 2010 at 10:01:09AM +0200, Stefano Zacchiroli wrote:
> On Sat, May 08, 2010 at 07:07:44PM +0200, Petter Reinholdtsen wrote:
> > Perhaps you are right. Perhaps we should do a poll to collect
> > information on how testers experience their boot with
> > CONCURRENCY=makefile, to make i
Stefano Zacchiroli wrote:
On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
CONCURRENCY=makefile
Where is this documented?
According to <4be43663.6000...@free.fr> and #576788, it is not.
But I'm sure Petter welcome patches on this.
FWIW, it appears to be documented in README.Deb
On Sun, May 09, 2010 at 01:24:49PM +0200, Marc Haber wrote:
> > CONCURRENCY=makefile
> Where is this documented?
According to <4be43663.6000...@free.fr> and #576788, it is not.
But I'm sure Petter welcome patches on this.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Un
[Stefano Zacchiroli]
> If you are ready to monitor the issue closely, I don't see any problem
> in switching the default now in unstable, see how it goes, and then
> decide later on if revert back to the current default in Squeeze
> time. Ideally, you should probably communicate a on the matter whe
On Sat, 8 May 2010 11:47:40 +0200, Julien Cristau
wrote:
>As far as I'm concerned, "faster boot" is irrelevant. Using an init
>daemon that actually does its job of supervising services, and lets us
>get rid of most of the stupidity and boilerplate of init scripts, otoh,
>is overdue.
What is so b
On Sat, 8 May 2010 11:51:22 +0200, Stefano Zacchiroli
wrote:
>On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
>> So it is the classical desktop vs. server situation. For my Debian
>> servers, that get booted at most once a month, I don't give a damn
>> about a faster boot.
>>
>> I _do
On Thu, 06 May 2010 21:11:56 +0200, Petter Reinholdtsen
wrote:
>These days, the init.d script dependencies in Squeeze are quite
>complete, so complete that it is actually possible to run all the
>init.d scripts in parallell based on these dependencies. If you want
>to test your Squeeze system, ma
On May 09, Stefano Zacchiroli wrote:
> I've just read a few days ago the design document of systemd; AFAIU it
> requires anyhow patching various daemons, no matter how trivial the
> patches are.
Patching the daemons is needed if you want it to open the listening
sockets for them. If you do not, i
On 08/05/2010 19:07, Petter Reinholdtsen wrote:
Perhaps we should do a poll to collect
information on how testers experience their boot with
CONCURRENCY=makefile, to make it easier to switch with some confidence
that it would work for most users. :)
If that helps, reading this thread i've set t
On 8 May 2010 19:07, Petter Reinholdtsen wrote:
> Perhaps you are right. Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, to make it easier to switch with some confidence
> that it would work for most users. :)
It just came t
On Sun, May 09, 2010 at 08:06:12AM +0200, Tollef Fog Heen wrote:
> I just filed an ITP on systemd and am planning on
Amazing!, thanks for this.
> making it installable alongside with sysvinit, switchable with
> init=/sbin/systemd when booting. Eventually, I guess either using
> alternatives for
On Sat, May 08, 2010 at 07:07:44PM +0200, Petter Reinholdtsen wrote:
> Perhaps you are right. Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, to make it easier to switch with some confidence
> that it would work for most users.
]] (Marco d'Itri)
| Removing the Essential flag from sysvinit would allow interested admins
| to install upstart on their systems if they want to benefit from its
| features. I am not sure how much useful it would be to also switch to
| upstart by default in this scenario, I welcome other opinion
On May 07, Julien Cristau wrote:
> > - a decision to drop kfreebsd as a release architecture
> Since 1 and 2 aren't happening, I think we should consider going with
> the third option.
Me too, I believe that the people interested in kfreebsd-* have had more
than enough time to provide the compat
[Kai Wasserbäch]
> as one of the testers just a short reply: on several desktops and
> some basic servers insserv in conjunction with
> "CONCURRENCY=makefile" works well. I didn't have an unbootable
> system so far.
Thank you. Note that I do not expect an unbootable system. The worst
I expect a
Hello Petter,
Petter Reinholdtsen schrieb am 08.05.2010 19:07:
> Perhaps we should do a poll to collect
> information on how testers experience their boot with
> CONCURRENCY=makefile, [...]
as one of the testers just a short reply: on several desktops and some basic
servers insserv in conjunction
[Stefano Zacchiroli]
> Fair enough. IMO you've done quite a lot of communication on the matter
> (at least to us developers) and I've personally been testing
> CONCURRENCY=makefile in response to your repeated call for testers. At
> this point, I doubt you can get significantly more testers without
On 05/08/2010 11:47 AM, Julien Cristau wrote:
On Fri, May 7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:
(Beside the nitpick on "we want" vs "we possibly want") I'd argue that
it's because we want a faster boot from our users ASAP.
As far as I'm concerned, "faster boot" is irrelevant.
On 05/07/2010 09:59 AM, Mike Hommey wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>>> These days, the init.d script dependencies in Squeeze are quite
>>> complete, so complete that it is actually possi
On Fri, May 07, 2010 at 10:06:52AM +0200, Petter Reinholdtsen wrote:
> All of this is based on my belief that there are very few people
> testing with CONCURRENCY=makefile. If a lot of people are using it
> successfully, it is less likely that there are many race conditions
> and edge cases left t
On Sat, May 08, 2010 at 11:37:10AM +0200, Marc Haber wrote:
> So it is the classical desktop vs. server situation. For my Debian
> servers, that get booted at most once a month, I don't give a damn
> about a faster boot.
>
> I _do_ care, however, about not having migrations in the boot process
> w
On Fri, May 7, 2010 at 19:27:54 +0200, Stefano Zacchiroli wrote:
> (Beside the nitpick on "we want" vs "we possibly want") I'd argue that
> it's because we want a faster boot from our users ASAP.
>
As far as I'm concerned, "faster boot" is irrelevant. Using an init
daemon that actually does its
On Fri, 7 May 2010 19:27:54 +0200, Stefano Zacchiroli
wrote:
>On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
>> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
>> wrote:
>> >The init.d world has changed quite a bit in recent years and might
>> >change even more in the next, it
Vincent Danjean wrote:
> Having a compat layer would also allow
> to stick to sysvinit on linux ports. I think this is very important
> because *lots* of system uses local sysvinit scripts and does not have
> ported them to upstart (not even to inserv dependency...)
Support for SysV init scripts
On Fri, May 07, 2010 at 06:15:24PM +0200, Marc Haber wrote:
> On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli wrote:
> >The init.d world has changed quite a bit in recent years and might
> >change even more in the next, it is possible that for Squeeze+1 we'll
> >want to be elsewhere than at
On Fri, 7 May 2010 09:26:18 +0200, Stefano Zacchiroli
wrote:
>The init.d world has changed quite a bit in recent years and might
>change even more in the next, it is possible that for Squeeze+1 we'll
>want to be elsewhere than at CONCURRENCY=makefile.
If we want to be elsewhere for squeeze+1, why
Since -bsd@ might be interested, Cc-ing them:
Steve Langasek (07/05/2010):
> On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> > On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
>
> > > [Aaron Toponce]
> > > > I thought Upstart was on the list for release in Sqe
On 07/05/2010 16:24, Julien Cristau wrote:
> On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
>
>> Upstart doesn't work on any kernels other than Linux. The original goal was
>> to have a compat layer to pull upstart jobs into the sysvinit system, which
>> would both address the hurd
On Fri, May 7, 2010 at 15:47:39 +0200, Steve Langasek wrote:
> Upstart doesn't work on any kernels other than Linux. The original goal was
> to have a compat layer to pull upstart jobs into the sysvinit system, which
> would both address the hurd/BSD kernel issues and allow a soft transition to
On Fri, May 07, 2010 at 03:15:25PM +0200, Julien Cristau wrote:
> On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
> > [Aaron Toponce]
> > > I thought Upstart was on the list for release in Sqeeze. Has this changed?
> > > http://lists.debian.org/debian-devel-announce/2009/09/msg
[Julien Cristau]
> What are the "needed pieces"?
I am sorry, do not have time to write a full update, so I give a quick
pointer instead. The list we use to discuss the boot system work is
initscripts-ng-de...@. See for example
http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2010-Ma
On Fri, May 7, 2010 at 14:57:08 +0200, Petter Reinholdtsen wrote:
>
> [Aaron Toponce]
> > I thought Upstart was on the list for release in Sqeeze. Has this changed?
> >
> > http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
>
> It is still on the wishlist, but the needed pieces
[Aaron Toponce]
> I thought Upstart was on the list for release in Sqeeze. Has this changed?
>
> http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
It is still on the wishlist, but the needed pieces are not ready, so
it seem unlikely to happen this late in the release process. A
On 5/7/2010 2:33 AM, Paul Wise wrote:
> Other distros are using upstart:
>
> http://upstart.ubuntu.com/
I thought Upstart was on the list for release in Sqeeze. Has this changed?
http://lists.debian.org/debian-devel-announce/2009/09/msg3.html
--
. O . O . O . . O O . . . O .
. . O
On May 07, Mike Hommey wrote:
> And kernel+initramfs. That's more than half the boot time (without
> even CONCURRENCY=makefile) here.
I am still waiting for an answer from the kernel/initramfs-tools
maintainer about moving udevsettle from init-top to premount.
--
ciao,
Marco
signature.asc
Des
On Fri, May 07, 2010 at 10:22:14AM +0200, Goswin von Brederlow wrote:
> Did you actualy read the mail till the end?
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-de...@lists.alioth.debian.org
Yes, I did, and I noticed that none of those bugs are RC severity,
that's why I've e
On Fri, May 7, 2010 at 4:22 PM, Goswin von Brederlow wrote:
> Stefano Zacchiroli writes:
>> The init.d world has changed quite a bit in recent years and might
>> change even more in the next, it is possible that for Squeeze+1 we'll
>> want to be elsewhere than at CONCURRENCY=makefile.
>
> Yet aga
Stefano Zacchiroli writes:
> On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
>> These days, the init.d script dependencies in Squeeze are quite
>> complete, so complete that it is actually possible to run all the
>> init.d scripts in parallell based on these dependencies.
>
On Fri, May 7, 2010 at 2:59 PM, Mike Hommey wrote:
> On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
>> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
>> > These days, the init.d script dependencies in Squeeze are quite
>> > complete, so complete that it is act
[Stefano Zacchiroli]
> From your message I can't exactly tell why we can't have it for
> Squeeze. My personal experience is that I've been using
> CONCURRENCY=makefile since several months now, and I've never run
> into problems.
I know there are bugs in the dependencies, which only affect some
c
On Fri, May 07, 2010 at 09:47:36AM +0200, Josselin Mouette wrote:
> Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> > These days, the init.d script dependencies in Squeeze are quite
> > complete, so complete that it is actually possible to run all the
> > init.d scripts in paral
Le jeudi 06 mai 2010 à 21:11 +0200, Petter Reinholdtsen a écrit :
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies. If you want
> to test your Squeeze syst
On Thu, May 06, 2010 at 09:11:56PM +0200, Petter Reinholdtsen wrote:
> These days, the init.d script dependencies in Squeeze are quite
> complete, so complete that it is actually possible to run all the
> init.d scripts in parallell based on these dependencies.
> Running scripts in parallel could
80 matches
Mail list logo
