Le 15/06/2015 01:14, Laurent Bercot a écrit :
(We should take this to the supervision list, this is becoming
seriously off-topic for dng.)
Dear Laurent,
My opinion is that it is not off-topic at all. Instead it is
central. Fast init, readiness signalling and supervision are the prim
On Mon, Jun 15, 2015 at 09:12:36PM +0200, Klaus Hartnegg wrote:
> Am 14.06.2015 um 23:17 schrieb Isaac Dunham:
> >Quite honestly, it really *does* matter to me that I can boot Alpine
> >Linux on my netbook in ~5 seconds rather than the ~10 seconds
>
> Just a single issue caused by the complexity b
Am 14.06.2015 um 23:17 schrieb Isaac Dunham:
Quite honestly, it really *does* matter to me that I can boot Alpine
Linux on my netbook in ~5 seconds rather than the ~10 seconds
Just a single issue caused by the complexity by systemd wastes more time
than all saved boot seconds can ever sum up t
On 15/06/2015 05:57, Isaac Dunham wrote:
(3) Server uses "not-a-supervisor":
# write a small C wrapper that forks, execs server in child,
# accepts s6-style notification and exits in parent
fake-sv -d 1 server
client
The main reason why I advocate such a simple notification style is
that this
On Mon, Jun 15, 2015 at 01:14:51AM +0200, Laurent Bercot wrote:
> On 15/06/2015 00:36, Isaac Dunham wrote:
> >I think that a program that must run in the background is broken.
> >Yet *prohibiting* auto-backgrounding imposes an even more heavy toll
> >on scripts where requires to be running and
>
On 15/06/2015 00:36, Isaac Dunham wrote:
I think that a program that must run in the background is broken.
Yet *prohibiting* auto-backgrounding imposes an even more heavy toll
on scripts where requires to be running and
ready: you *must* run a supervisor, or else run a lame-not-quite-a-
supervi
On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote:
> On 12/06/2015 22:21, marc...@welz.org.za wrote:
> >The trick is for the daemon process to only background when
> >it is ready to service requests (ie its parent process exits
> >when the child is ready).
>
> This is bad design, for
On Sat, Jun 13, 2015 at 09:42:34AM -0400, Steve Litt wrote:
> On Sat, 13 Jun 2015 10:37:19 +0100
> KatolaZ wrote:
> > I think there is another, more fundamental question: do we really need
> > to know in *real time* when a service/daemon is ready for its job or
> > has done what it is supposed to
My take-away from this and the related threads is that a daemon author
would ideally provide options to have it:
* Either write log messages to stderr or syslog, but write the same data
regardless;
* Either stay running in the foreground, or auto-background itself once
it's ready to begin taking re
On 06/13/2015 09:34 AM, Klaus Hartnegg wrote:
Am 13.06.2015 um 13:33 schrieb Laurent Bercot:
30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?
This would mean less than what most people think. Because everything
longer than half a second is perceived as bein
On 13/06/2015 08:40, Didier Kryn wrote:
Yes, daemon writers are good-willing developpers; they want their
software to serve as many users as possible; and users install
distros. This gives power to the distros. But if someone provides
them with a KISS readyness-signaling method, along with a syst
On Sat, 13 Jun 2015 10:43:52 +0200
marc wrote:
> On a personal note: You have been making a number of pronouncements
> which suggest incomplete understanding of unix: Here unaware of
> dup2(), but in previous posts you were unclear on when a shell needs
> to do a stat() (5542b2d4.5030...@skarnet.
On Sat, 13 Jun 2015 10:37:19 +0100
KatolaZ wrote:
> On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote:
>
> [cut]
>
> >
> > The question now is who will develop, maintain and package this
> > wrapper? Will Devuan be the official developper of
> > "Systemd-Readyness-Wrapper", or ca
Am 13.06.2015 um 13:33 schrieb Laurent Bercot:
30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?
This would mean less than what most people think. Because everything
longer than half a second is perceived as being forced to wait. As long
as an improvement st
Am 13.06.2015 um 08:40 schrieb Didier Kryn:
Yes, daemon writers are good-willing developpers; they want their
software to serve as many users as possible; and users install distros.
This gives power to the distros. But if someone provides them with a
KISS readyness-signaling method, along wi
On 13/06/2015 11:37, KatolaZ wrote:
AFAIK all this fuss with
"daemon-readiness" began with the first attempts to have parallel boot
sequences, which is something that is still *useless* in 95% of the
use cases: servers don't get restarted evey other minute and "normal"
users who don't use suspen
On 13/06/2015 10:43, marc wrote:
It is only bad design if you have your heart set on a supervision
framework like daemontools.
No, it is bad design because
- it lengthens the code path before the service is operational
- it requires software authors to write more code into their
daemon inste
On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote:
[cut]
>
> The question now is who will develop, maintain and package this
> wrapper? Will Devuan be the official developper of
> "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who
> else to take the job? Or are the
> On 12/06/2015 22:21, marc...@welz.org.za wrote:
> >The trick is for the daemon process to only background when
> >it is ready to service requests (ie its parent process exits
> >when the child is ready).
>
> You already mentioned it in a reply to me, indeed. I intentionally
> did not follow up,
Le 13/06/2015 01:15, Laurent Bercot a écrit :
Encouraging daemon writers to use another API and providing a wrapper
to make daemons using the simpler API work with the sd_notify mechanism
is clearly the better ideological solution, and also technologically
preferable because more compatible with
Le 13/06/2015 01:53, Laurent Bercot a écrit :
On 12/06/2015 22:21, marc...@welz.org.za wrote:
The trick is for the daemon process to only background when
it is ready to service requests (ie its parent process exits
when the child is ready).
You already mentioned it in a reply to me, indeed. I
On Fri, 12 Jun 2015 22:21:06 +0200
marc...@welz.org.za wrote:
> The trick is for the daemon process to only background when
> it is ready to service requests (ie its parent process exits
> when the child is ready).
For those of us who use daemontools-inspired process managers or inits,
the pre
On 12/06/2015 22:21, marc...@welz.org.za wrote:
The trick is for the daemon process to only background when
it is ready to service requests (ie its parent process exits
when the child is ready).
You already mentioned it in a reply to me, indeed. I intentionally
did not follow up, and here is w
On 12/06/2015 20:09, Tomasz Torcz wrote:
Hey, it's almost exactly what sd_notify() does. Instead of one character,
it writes "READY=1" to a socket. Nothing more, no D-Bus, no additional
libraries needed. In basic form it few lines of C code.
Of course
https://github.com/systemd/systemd/b
On 12/06/2015 19:46, Steve Litt wrote:
I agree with every single thing you write above, but have one question
for you: What does Devuan do when daemons like cupsd and sshd make
sd_notify calls, and these don't condition the call on sd_notify being
available, and sd_notify cannot be conditionally
> For months, literally, the supervision list
> has been wringing its hands over the very real problem that, for process
> dependency purposes, one must know that process X is not only running,
> but ready to handle its business. Knowing process X is running isn't
> sufficent, because some processe
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote:
> Please don't do this.
> The more you bend to the systemd interfaces, the more it gets a foot
> in the door. By implementing a dummy sd_notify, you acknowledge the
> validity of the interface; you accept that the systemd people have
On Fri, Jun 12, 2015 at 07:37:21PM +0200, Laurent Bercot wrote:
> On 12/06/2015 19:01, Steve Litt wrote:
> >The one thing I *do* know is that we need to provide a sd_notify
> >interface, even if it does nothing at all and drops passed information
> >on the floor.
>
>
> There's a much simpler mec
On Fri, Jun 12, 2015 at 01:46:41PM -0400, Steve Litt wrote:
[cut]
>
> Hi Laurent,
>
> I agree with every single thing you write above, but have one question
> for you: What does Devuan do when daemons like cupsd and sshd make
> sd_notify calls, and these don't condition the call on sd_notify be
On 12/06/2015 19:46, Steve Litt wrote:
I agree with every single thing you write above, but have one question
for you: What does Devuan do when daemons like cupsd and sshd make
sd_notify calls, and these don't condition the call on sd_notify being
available, and sd_notify cannot be conditionally
On Fri, 12 Jun 2015 19:37:21 +0200
Laurent Bercot wrote:
> On 12/06/2015 19:01, Steve Litt wrote:
> > The one thing I *do* know is that we need to provide a sd_notify
> > interface, even if it does nothing at all and drops passed
> > information on the floor.
>
> Please don't do this.
> The
On 12/06/2015 19:01, Steve Litt wrote:
The one thing I *do* know is that we need to provide a sd_notify
interface, even if it does nothing at all and drops passed information
on the floor.
Please don't do this.
The more you bend to the systemd interfaces, the more it gets a foot
in the door.
32 matches
Mail list logo
