Rob Owens writes:
>> From: "Rainer Weikusat"
>> Laurent Bercot writes:
>
>>> I'm talking normal use cases here, i.e. situations where the services
>>> *will* succeed. In those situations, it is better to start everything
>>> according to the dependency graph, because then you do *not* trigger
>
On 28/09/2015 22:05, Rob Owens wrote:
Here is a real-world scenario that has caused me trouble over the years.
I have a system that connects wirelessly to my local network. The system
uses wicd to manage the network connections, and wicd starts at boot.
This system is supposed to mount several N
- Original Message -
> From: "Rainer Weikusat"
> Laurent Bercot writes:
>> I'm talking normal use cases here, i.e. situations where the services
>> *will* succeed. In those situations, it is better to start everything
>> according to the dependency graph, because then you do *not* trigg
Laurent Bercot writes:
> On 25/09/2015 17:29, Simon Hobson wrote:
[...]
>> Of course, regardless of what system or definitions you use - if a
>> service then dies then you have a problem. IMO, "it might die at some
>> indeterminate time" isn't an excuse for not trying to get the "start
>> stuff
Simon Hobson writes:
[...]
> Rainer Weikusat wrote:
>
>>> * anything that uses the syslog should start after the syslog.
>>
>> That's the same misunderstanding already shown elsewhere: Starting
>> syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
>> 'very small', does not
On 25/09/2015 17:29, Simon Hobson wrote:
Windows and MacOS both prioritise those tasks needed to get a desktop
picture (or login prompt) on the screen - as that gives the illusion
of fast boot time.
Oh, yes, definitely. (My client machine runs Windows, and I experience
that every day.)
It doe
On Fri, Sep 25, 2015 at 03:59:19PM +0200, Laurent Bercot wrote:
> On 25/09/2015 09:05, Simon Hobson wrote:
>
>
> >There's nothing that gets people impatient
> >better than something that appears to be taking a long time "doing
> >nothing" !
>
> Show them a terminal with a lot of scrolling gibbe
Laurent Bercot wrote:
> On 25/09/2015 09:05, Simon Hobson wrote:
>> More to the point, I'd rather have reliability over speed any day.
>
> How about you get both?
Well yes, that's better still.
> The dichotomy is a false one. People believe they can't have both
> because init systems have neve
On Fri, Sep 25, 2015 at 07:01:16AM +0100, KatolaZ wrote:
> On Thu, Sep 24, 2015 at 09:28:28PM +0200, Jaromil wrote:
>
> [cut]
>
> > >
> > > But let's be honest here: how many times does it happen that you have
> > > to reboot a production server nowadays?
> >
> > I think you are overlooking the
Jaromil writes:
> On Fri, 25 Sep 2015, Simon Hobson wrote:
[...]
> What I'm particularly interested is something to do process monitoring
> and respawning for a certain group of daemons - bundle in s6-rc? however
> not necessarily mixed with the system-wide base daemons. For instance
> in Dowse
On Fri, Sep 25, 2015 at 03:40:35PM +0200, Didier Kryn wrote:
[cut]
>
> But, as you or Jaromil said, and we all agree on this, the
> important thing is that Devuan provide this new high quality
> software, so that admins have more freedom. Important also is the
> fact that fast and dependency
On 25/09/2015 11:27, KatolaZ wrote:
I actually had the impression that servers was what Laurent was
referring to... :)
Was I? It's possible.
I usually refer to servers because it's the environment I'm used
to; but what I'm saying about boot times, parallelism and so on
is also true for client
Isaac Dunham writes:
> On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote:
>> Laurent Bercot writes:
>>
>> [...]
>>
>> > It manages dependencies between services, no matter whether they are
>> > oneshots or longruns; it can intertwine oneshot starts and longrun
>> > starts, or ones
On 25/09/2015 09:26, Jaromil wrote:
What I'm particularly interested is something to do process monitoring
and respawning for a certain group of daemons
Just supervise the daemons you want to supervise, and don't
supervise the ones you don't want to. But really, there's no
reason *not* to supe
On 25/09/2015 09:05, Simon Hobson wrote:
More to the point, I'd rather have reliability over speed any day.
How about you get both?
The dichotomy is a false one. People believe they can't have both
because init systems have never been done right so far, and always
forced them to choose betwee
Le 25/09/2015 11:27, KatolaZ a écrit :
On Fri, Sep 25, 2015 at 11:06:50AM +0200, Didier Kryn wrote:
Le 24/09/2015 19:54, KatolaZ a écrit :
But let's be honest here: how many times does it happen that you have
to reboot a production server nowadays? It is quite rare that a
failing program actual
On Fri, Sep 25, 2015 at 11:06:50AM +0200, Didier Kryn wrote:
> Le 24/09/2015 19:54, KatolaZ a écrit :
> >But let's be honest here: how many times does it happen that you have
> >to reboot a production server nowadays? It is quite rare that a
> >failing program actually needs a reboot, right? And ev
Le 24/09/2015 19:54, KatolaZ a écrit :
But let's be honest here: how many times does it happen that you have
to reboot a production server nowadays? It is quite rare that a
failing program actually needs a reboot, right? And even when it
happens, 1 minute or 5 minutes boot won't change your overa
On Fri, Sep 25, 2015 at 08:05:42AM +0100, Simon Hobson wrote:
[cut]
>
> But, if you are going to boot slowly and methodically, it helps if there's
> signs of progress. There's nothing that gets people impatient better than
> something that appears to be taking a long time "doing nothing" !
>
On Fri, 25 Sep 2015, Simon Hobson wrote:
> KatolaZ wrote:
>
> > Just please try to avoid falling in the same "everybody needs to
> > boot-up in 12 seconds because high availability requires so"
> > rhetoric championed by systemd-fanboys.
>
> More to the point, I'd rather have reliability over s
KatolaZ wrote:
> Just please try to
> avoid falling in the same "everybody needs to boot-up in 12 seconds
> because high availability requires so" rhetoric championed by
> systemd-fanboys.
More to the point, I'd rather have reliability over speed any day. If the
system boots reliably in 2 minut
On Thu, Sep 24, 2015 at 09:28:28PM +0200, Jaromil wrote:
[cut]
> >
> > But let's be honest here: how many times does it happen that you have
> > to reboot a production server nowadays?
>
> I think you are overlooking the vastity of use-cases here and I agree
> with Laurent for a 5 minutes down
On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote:
> Laurent Bercot writes:
>
> [...]
>
> > It manages dependencies between services, no matter whether they are
> > oneshots or longruns; it can intertwine oneshot starts and longrun
> > starts, or oneshot stops and longrun stops. Wh
Rainer Weikusat wrote:
> ... or the fact that apache on the box I'm presently
> using 'depends' on bind and syslog.
Well in the general case*, those are not unreasonable dependencies. In the
general case*, Apache needs** DNS resolution during startup, and it rather
makes sense** if it's able t
On 24/09/2015 21:23, Steve Litt wrote:
What's the benefit of having the shortest run-time code path of any
service manager?
- Speed: a short run-time code path means that less instructions are
executed, so the job is done faster. The point is to do the amount
of necessary work (calling the scr
Steve Litt writes:
> On Thu, 24 Sep 2015 14:31:40 +0100
> Rainer Weikusat wrote:
>
>> Laurent Bercot writes:
>>
>> [...]
>>
>> > It manages dependencies between services, no matter whether they are
>> > oneshots or longruns; it can intertwine oneshot starts and longrun
>> > starts, or oneshot
Jaromil writes:
> congrats to the on-time release Laurent!
>
> dear Katolaz and others
>
> On Thu, 24 Sep 2015, KatolaZ wrote:
>
>> On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote:
>> > On 24/09/2015 17:51, Rainer Weikusat wrote:
>> > >If it starts working within less than five minu
On Thu, 24 Sep 2015 15:40:23 +0100
Rainer Weikusat wrote:
> Laurent Bercot writes:
> > On 24/09/2015 15:31, Rainer Weikusat wrote:
> >> I'd still very much like to see an actual example which really
> >> needs these depenencies which isn't either bogus or a workaround
> >> for a bug in the softw
On Thu, 24 Sep 2015 14:31:40 +0100
Rainer Weikusat wrote:
> Laurent Bercot writes:
>
> [...]
>
> > It manages dependencies between services, no matter whether they are
> > oneshots or longruns; it can intertwine oneshot starts and longrun
> > starts, or oneshot stops and longrun stops. When ch
congrats to the on-time release Laurent!
dear Katolaz and others
On Thu, 24 Sep 2015, KatolaZ wrote:
> On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote:
> > On 24/09/2015 17:51, Rainer Weikusat wrote:
> > >If it starts working within less than five minutes, users will
> > >forget
On Wed, 23 Sep 2015 23:44:36 +0200
Laurent Bercot wrote:
> s6-rc features the shortest run-time code path of any service
> manager to this day: this includes systemd, sysv-rc, and OpenRC.
What's the benefit of having the shortest run-time code path of any
service manager?
Thanks, and keep u
Laurent Bercot writes:
> On 24/09/2015 17:51, Rainer Weikusat wrote:
>> If it starts working within less than five minutes, users will forget
>> about it faster than they could complain, especially for a system which
>> is usually supposed to be running. But that's actually a digression.
>
> Five
On Thu, Sep 24, 2015 at 07:20:25PM +0200, Laurent Bercot wrote:
> On 24/09/2015 17:51, Rainer Weikusat wrote:
> >If it starts working within less than five minutes, users will forget
> >about it faster than they could complain, especially for a system which
> >is usually supposed to be running. But
On 24/09/2015 17:51, Rainer Weikusat wrote:
If it starts working within less than five minutes, users will forget
about it faster than they could complain, especially for a system which
is usually supposed to be running. But that's actually a digression.
Five minutes? And you think it's accept
Laurent Bercot writes:
> On 24/09/2015 16:40, Rainer Weikusat wrote:
>
>> Hence 'failure'
>> is part of the normal mode of operation and proccesses trying to use TCP
>> need to deal with that.
>
> Yeah, well, if your favorite startup mode is to start everything at
> the same time and say "eh, if
On Thu, Sep 24, 2015 at 05:04:51PM +0200, Laurent Bercot wrote:
[cut]
>
> >That's slightly different because it's obviously not possible to start a
> >program stored in a file (which needs various other files to start)
> >before accessing any of these files is possible (it's still subject to
> >
On 24/09/2015 16:40, Rainer Weikusat wrote:
Hence 'failure'
is part of the normal mode of operation and proccesses trying to use TCP
need to deal with that.
Yeah, well, if your favorite startup mode is to start everything at
the same time and say "eh, if it doesn't work, the program is suppos
Laurent Bercot writes:
> On 24/09/2015 15:31, Rainer Weikusat wrote:
>> I'd still very much like to see an actual example which really needs
>> these depenencies which isn't either bogus or a workaround for a bug in
>> the software being managed.
>
> Your network must be up before you do any netw
On 24/09/2015 15:31, Rainer Weikusat wrote:
I'd still very much like to see an actual example which really needs
these depenencies which isn't either bogus or a workaround for a bug in
the software being managed.
Your network must be up before you do any network connections.
Your DNS cache mu
Laurent Bercot writes:
[...]
> It manages dependencies between services, no matter whether they are
> oneshots or longruns; it can intertwine oneshot starts and longrun
> starts, or oneshot stops and longrun stops. When changing the machine
> state, it always ensures the consistency of the depen
> On September 23, 2015 at 5:44 PM Laurent Bercot wrote:
>
> >> if you can confirm the plan of releasing s6-rc within september
> > I confirm it.
>
> And, lo and behold, I'm on schedule for once.
> s6-rc-0.0.1.0 is out.
Expubident!
Peter Olson
41 matches
Mail list logo
