On 12/26/2015 12:09 PM, Steve Litt wrote:
Is this doable in a way consistent with supervision suites?
Pipelines can form practically indefinite graphs in scope owing to the
nature of fds (modulo process control limitations and space
constraints). You might be interested in pipexec, which
On 09/08/2015 11:44 PM, James Powell wrote:
I have wondered if OpenRC could have scripts that hook into s6 to start
services via s6 and run in supervision mode while having OpenRC manage order of
process startup and sysvinit handles the remainder of init functionality. In a
way you combine
I'm honestly struggling to think of a practical use case for this,
though I may be lacking sufficient context.
The case of a daemon breaking semantics of existing options is quite
seldom seen, and just a bad practice for reasons of maintaining least
surprise and compatibility. Even when major
Implying that the distributions would have transitioned from System
V-style to daemontools-style mechanisms?
Strongly doubt it.
For all the noise and controversy that's been happening over PID1, I
always got the impression that most distros back in the day simply
didn't care. They happily
In fairness, readiness notification does seem to require
application-specific integration in general under current constraints of
most Unixes.
Good work, nonetheless. sd_notify isn't complicated, to their credit.
On 06/13/2015 02:48 PM, Laurent Bercot wrote:
Hello,
A part of systemd's
This is indeed the generally correct order, though I think it's a bit
too primitive for real-world shutdown on more dynamic systems,
particularly desktops. It's good practice to touch /etc/nologin or
/run/nologin, sync the dirty buffers to disk, turn off swap, detach
loopback and volumes
(Gah, idiotically neglected the proper destination.)
It seems to me that the domineering philosophy for fault tolerance is,
indeed, to let it crash and let the individual state management of
services coupled with any existing supervisor trees and priority
rankings to do their work.
From my
On 01/26/2015 10:10 PM, Laurent Bercot wrote:
- New commands: s6-svlisten and s6-svlisten1. They do for services what
s6-ftrig-listen and s6-ftrig-listen1 do for regular fifodirs.
Were these by any chance inspired by aux/listen and aux/listen1 from Plan 9?
On 01/22/2015 01:33 AM, Avery Payne wrote:
This brings to mind the discussion from Jan. 8 about ./provides,
where a defining a daemon implies:
* the service that it actually provides (SMTP, IMAP, database, etc.);
think of it as the doing, the piece that performs work
* a data transport
On 01/21/2015 06:09 PM, Wayne Marshall wrote:
4) in general, folks here are letting their panties get far too twisted
with the dependency problem. Actual material dependencies are
relatively few and can be easily (and best) accomodated directly in the
runscript of the dependent service. See
On 01/15/2015 07:05 PM, Steve Litt wrote:
Hi all,
I'm writing you because you're by far the most init aware people I
know. I've created a web page about features and benefits of a few init
systems. The audience for this web page isn't people like all of you,
but instead for the average DIY
On 01/06/2015 07:48 AM, Laurent Bercot wrote:
Interesting. Thanks for the heads-up - I had heard of tsort, but didn't
know exactly what it does.
However, I'd like a tool that knows what steps it can parallelize.
A sequential output is great for functions name in a piece of code,
but for
12 matches
Mail list logo
