On 08/04/2014 22:59, Asif Iqbal wrote:
Hi All,
Can runit supervise multithreaded appliacation like tac_plus?
tac_plus: https://github.com/mkouhei/tacacs-plus
man tac_plus
-G Remain in the foreground, but not single-threaded nor logging to the
tty.
Hi Asif,
This is all a supervision
On 24/06/2014 09:03, Vincent de RIBOU wrote:
Can you summarize your feeling against systemd.
It's not a question of feelings, it's a question of technical
merit. You can find various arguments for, or against, systemd
out there, and I very much do not wish to import *that* discussion
into
On 22/07/2014 22:57, Joe M wrote:
I read that dragora moved from runit to perp as runit was not being
maintained.
Just wanted to check if runit is not being actively maintained and if
perp is a better option going forward.
runit, as perp, don't need to be actively maintained because they
On 26/07/2014 20:47, Joan Picanyol i Puig wrote:
What tricky responsabilities are you thinking of for /sbin/init that
would make it Linux specific?
s6-svscan wants a read-write directory to run in, and another to
run its logger in. I definitely want to support read-only root
filesystems, and
On 03/10/2014 06:38, Avery Payne wrote:
So, should I stop work on runit-scripts and s6-scripts? If this is all for
naught, then why put the effort in?
I didn't say that, duh. I said it was a hard problem to solve in the general
case, that there was no simple shortcut, and that the framework
Le 20/10/2014 19:52, John Albietz a écrit :
- With nearly all of my services, I create enable scripts that check for,
and if necessary set up directories and perhaps even default passwords or
databases. And I haven't found an elegant way yet to integrate this into
runit. I think it would be
First, I need to apologize, because I spend too much time talking and
dismissing ideas, and not enough time coding and releasing stuff. The
thing is, coding requires sizeable amounts of uninterrupted time - which
I definitely do not have at the moment and won't until December or so -
while
Le 31/10/2014 21:04, Avery Payne a écrit :
The reason I was attempting to tackle process dependencies is
actually driven by dbus friends. I've stumbled on many modern
processes that need to have A, and possibly B, running before they
launch. Of course, you are right, in the perspective that
On 22/12/2014 20:45, John Albietz wrote:
What is the upgrade path from pre 2.0.0.0 s6 installs to 2.0.0.0. Are there
any major compatibility issues?
With the new major version in the release number, not sure if I should
expect an upgrade to just *work*.
As far as I can tell, things should
Hi Toki,
Grats on trying out s6.
Since most of your troubles have to do with skalibs and not with s6 itself,
please use the skaw...@list.skarnet.org list. (Reply-To: set. I'd set
Mail-Followup-To: if I knew how to tell Thunderbird to do so. .)
My answers below.
First, a minor note: Why
Hi James,
I have had a though, why not include symlinkable functionality for
halt, poweroff, shutdown, and reboot directly in s6-svscanctl
s6-svscan can be used as a normal process, not only as process 1,
and there can be more than one scan directory on the system.
Calling s6-svscanctl
On 03/01/2015 01:13, Avery Payne wrote:
I'm thinking spawn to background and exit just after that.
That solves the problem I mentioned, but creates other ones.
If ./finish is about cleanup, and you background it, then ./run
may start again before the cleanup has completed, so there will
be
On 21/01/2015 18:24, Olivier Brunel wrote:
I'll have to setup some scripts for different init stages, using
s6-svscan as stage 2, as you've described elsewhere. But I also want to
have a system to start (and stop) services in order. I see this whole
idea of order/dependency is something that is
On 21/01/2015 00:20, Olivier Brunel wrote:
Cool; I see you've also added a tainstamp into the ready file, that's
good but you forgot to update the doc of s6-notifywhenup as well, which
still talks of empty file.
Fixed in current git.
--
Laurent
On 21/01/2015 21:47, Olivier Brunel wrote:
The thing is, that you've referred to services oneshots, whereas I
would refer to longrun services oneshot services resp., i.e. I see
those as two types of services.
They are both services from a system management, higher-level, point
of view. From
On 16/01/2015 01:05, Steve Litt wrote:
http://www.troubleshooters.com/linux/init/features_and_benefits.htm
(I'm lacking sleep and I'm going to talk about systemd. Not a good
combination. So, apologies in advance for the rant, for the inevitable
coarse language, and for the very opinionated
On 20/01/2015 19:04, Olivier Brunel wrote:
I see... Well, thing is, as you said, support for the ready file is
already more than just s6-notifywhenup, since s6-supervise takes care of
removing it when needed, or s6-svwait also has support for it.
Yeah. I added the support to s6-svstat, to see
Hi Olivier !
Thanks for the patches. A bit of discussion below.
So I wanted to have the return code/signal that occured when a process went down
available on the statusfile, as I believe this is useful information to have for
all services.
Yes, that makes sense.
Looking into it, I
Hello,
* skalibs-2.3.0.0 is out. (Needed for the s6 release.)
Mostly bugfixes, and some additions for siovec management.
The major number has been bumped because some functions
(buffer_getvall, buffer_putvall) changed interfaces.
http://skarnet.org/software/skalibs/
Hello,
s6-2.1.0.1 is out.
It simply fixes two bugs:
- s6-2.1.0.0 would not build with clang
- s6-fdholder-daemon would incorrectly rewrite the -T option (which
is why I'm making another release so soon: can't have a visible bug,
no matter how minor, in the flagship program for the
On 27/01/2015 15:50, post-sysv wrote:
Were these by any chance inspired by aux/listen and aux/listen1 from Plan 9?
They were not - for the simple reason that I don't know Plan 9 at all.
(It's on my list of nice things to study when I get the time, which
probably won't happen for 2 or 3
On 06/01/2015 02:03, James Powell wrote:
The initial init bootscript that I'm currently drafting is in
execline using the template provided by Laurent. I was going to take
the advice on using /bin/sh rather than /bin/execlineb but I recanted
that decision due to the fact I wanted the using the
On 06/01/2015 09:00, Colin Booth wrote:
1. Depending on your initramfs and your on-disk layout you can skip
mounting proc and sys. I know this is the case with Debian, probably
true elsewhere as well.
It all depends on the assumptions that init-stage2 makes, but yes,
now that you're
On 06/01/2015 13:12, Peter Pentchev wrote:
Even better: most modern systems have a tsort(1) utility for this kind of
topological sorting; BSD-derived systems have had it for ages.
Interesting. Thanks for the heads-up - I had heard of tsort, but didn't
know exactly what it does.
However, I'd
On 07/01/2015 09:16, Luke Diamand wrote:
One small concern would be that it's not enough to simply signal a
dependency to be up - it needs to be actually running and working
before you can start the dependent service successfully. To take my
[least-]favourite example, you can't start autofs
Greetings,
s6-2.0.1.0 is out.
It fixes the issue that some people encountered with parallel builds
(make -j2).
There's a new program, s6-applyuidgid, that is a more generic
s6-setuidgid, meant to be called by programs that want to drop
privileges automatically. (The s6-networking
On 09/02/2015 18:50, Buck Evan wrote:
Is there truly no public access to the source control for runit?
If so, it's decidedly odd.
Not that odd.
Small projects don't really need an SCM. Most pre-git SCMs are
cumbersome or impractical. runit predates git. Gerrit chose to
focus on the code, not
Yeah, it's a bug in ezmlm-cgi, and I haven't investigated it yet.
Not sure if it's non-ascii content or something else, but some messages
just make ezmlm-cgi crash. I'll look into it and hopefully fix it (or
file a precise bug-report) at some point. Not a priority though, since
mail-archive.com
In the meantime, I've set up a more user-friendly behaviour when a crash
happens. I should have done it sooner.
--
Laurent
On 15/02/2015 18:50, Gorka Lertxundi wrote:
s6-log: warning: unable to read current time - timestamps may be wrong for a
while: No such file or directory
Hi Gorka,
Please try pulling the latest git head of skalibs, and recompiling
skalibs (then s6 if you linked against the static version of
It was my fault, I thought the problem was related to standard libc vs musl but
it wasn’t.
No, it definitely wasn't. :)
I thought that might be a problem in skalibs, that's why I advised you
to try with the latest build, but it apparently wasn't either. Glad
you could make it work !
--
Here's an ugly hack that allows you do that using envdir:
set -a
eval $({ env; envdir ../.env env; } | grep -vF -e _= -e SHLVL= | sort | uniq -u)
set +a
Ugh, in the morning (almost) light it's even uglier than I thought,
because it won't work for values you *change* either, which could
be
On 05/01/2015 20:12, Caleb Spare wrote:
We're really happy with using runit/svlogd generally, but over time
we've found the TAI-timestamped filenames that svlogd produces, which
aren't human-readable, makes dealing with the logs too difficult.
Can't you run a simple filter like tai64nlocal or
On 07/01/2015 23:25, Avery Payne wrote:
The goal is the same but the emphasis has changed. This will be considered
a fall-back feature for those systems that do not have such a tool
available, or have constraints that force the continued use of a shell
launcher. It is the option of last
On 06/01/2015 18:46, Avery Payne wrote:
1. A service can ask another service to start.
2. A service can only signal itself to go down. It can never ask another
service to go down.
3. A service can only mark itself with a ./down file. It can never mark
another service with a ./down file.
I'm not sure exactly in what context your message needs to be taken
- is that about a tool you have written or are writing, or something
else ? - but if you're going to work on dependency management, it's
important that you get it right. It's complex stuff that needs
planning and thought.
*
On 20/03/2015 23:05, Avery Payne wrote:
question is: how difficult would it be to write a ./finish script in
execline?
It all depends on what you want to accomplish in your finish script,
of course. But there's no reason why it should be difficult: finish
scripts are essentially cleanup
I have added a documentation page to s6:
http://skarnet.org/software/s6/overview.html
Please read it, especially if you're still new to s6 or to
supervision in general, or if you had trouble understanding
what to do with s6 once you had installed it, or if you were
confused by the amount of
The idea is that with a docker-targeted s6 tarball, it should
universally work on top of any / all base image.
Just to make things perfectly clear: I am not going to make a
special version of s6 just for Docker. I like Docker, I think it's
a useful tool, and I'm willing to support it, as in
On 28/02/2015 11:58, Laurent Bercot wrote:
(In case you can't tell: I'm not a github fan.
Meh. At this time, publicity is a good thing for my software,
even if 1. it's still a bit early, and 2. I have to use tools
I'm not entirely comfortable with. So I set up mirrors of
everything
On 26/02/2015 19:37, Olivier Brunel wrote:
saying I feel this option makes sense on its own, not just to reduce the
number of executable to call, but because s6-envdir is used to define an
environment, having a way to guarantee what said environment will be
seems a good/logical thing.
Yes, it
Hello,
s6-2.1.1.2 is out. It fixes:
- a bug in s6-log that wasn't parsing correctly multiple sets of
selections/actions;
- a bug in s6-fdholderd that would crash when provided with certain
configurations.
It depends on skalibs-2.3.1.0 and execline-2.1.0.0, also newly released.
I fully agree with Colin on both points.
- For the s6-envdir thing: all the tools already exist to perform
what you want. Sure, adding an option isn't hard, and would make
things convenient, but it's a slippery slope. I try to provide
tools that perform basic operations and rely on users to
(Moving the discussion to the supervision@list.skarnet.org list.
The original message is quoted below.)
Hi Dreamcat4,
Thanks for your detailed message. I'm very happy that s6 found an
application in docker, and that there's such an interest for it!
skaw...@list.skarnet.org is indeed the
On 26/02/2015 21:53, John Regan wrote:
Besides, the whole idea here is to make an image that follows best
practices, and best practices state we should be using a process
supervisor that cleans up orphaned processes and stuff. You should be
encouraging people to run their programs, interactively
On 21/04/2015 23:19, TheOldFellow wrote:
I am trying to write the init-stage1 script, so (B). The initrd has
completed by the time it runs, since root is a lvm2 partition /dev
must be mounted in initrd so that /dev/mapper/'root' can be mounted
on /. That's the main function of my initrd,
On 22/04/2015 02:58, Buck Evan wrote:
Just to set my own expectations, may I send pull requests to github, or
must I send patches here?
Please send patches here. Even better, please start a design discussion
about the feature/change you want before writing a patch, unless it is
very small.
On 22/04/2015 00:35, Buck Evan wrote:
I believe the s6 project would benefit measurably from a move to github.
There's a github mirror of s6 already. Moving the main repository to
github, and using more github services, is not going to happen, for
both philosophical and technical reasons.
On 22/04/2015 01:40, Buck Evan wrote:
I didn't know until you two told me just now.
Can we have a link in the doc?
Good idea, thank you. Done now, in the Download section of
the main page.
For some reason, git remote is having trouble replicating the
change on to the github copy. It gives
On 21/04/2015 16:34, TheOldFellow wrote:
I have built a fresh LFS, it is on a LVM2 partition, so I need an
Initramfs, and this enters the Stage 1 script with a devtmpfs somewhat
populated, and /sys and /proc already mounted. My thinking is that these
mounts are OK, and I don't see any advantage
On 28/04/2015 20:49, Avery Payne wrote:
Good point, I'm going to stop discussion here and go over there, where the
discussion belongs.
That's not what I meant :)
Keep your thread here, it interests people who are not subscribed
to skaware, and it will be simpler. But please come over there
On 11/04/2015 13:46, Olivier Brunel wrote:
But if the two projects are pretty much the same, might be worth joining
forces indeed...
Cool. I'll make another thread and stop hijacking yours. ;)
--
Laurent
On 04/06/2015 22:41, Jameson Graef Rollins wrote:
What I would like is to somehow stagger the startup of the processes, to
avoid the resource contention. I could do this by putting a random
sleep into the ./run scripts, but this would also cause random startup
delays on subsequent process
What you really want is a real service manager that works on top
of a process supervision system and that would managed a complete,
ordered initialization sequence for you.
Steve is saying that process supervisors are lacking real service
management capabilities, and he's right. Process
On 08/06/2015 16:00, Avery Payne wrote:
This is where I've resisted using sockets. Not because they are bad
- they are not. I've resisted because they are difficult to make
100% portable between environments. Let me explain.
I have trouble understanding several points of your message.
-
On 08/06/2015 22:40, Jonathan de Boyne Pollard wrote:
As to whether opening server sockets early is a good idea: I'm not in
a hurry to naysay. It achieves the stated effect. Arguably, indeed,
it can be described as *what the system already does* if one has a
lot of daemontools-style services
On 23/06/2015 12:40, Lasse Kliemann wrote:
At the moment, I am just interested in whether people (especially people
on this list) believe there is something wrong with slashpackage, and if
so, what it is in particular.
Short answer: it's a political issue, not a technical one.
Long answer:
Hello,
s6-2.1.5.0 is out.
It adds support of SIGHUP to s6-log for a clean exit even when the
-p option is present.
This is useful when bringing down a supervision tree logging its
output into a s6-log -p instance: the instance survives, but the
.s6-svscan/finish script still has a fd open
Hello,
(It's always like that. No matter how many checks you perform before
hitting the release button, you always discover the worst bugs right
afterwards.)
s6-2.1.6.0 is out.
It adds a -X command to s6-svc, that is like -x except it makes s6-supervise
instantly close its
On 11/06/2015 23:34, Steve Litt wrote:
I have a feeling that SIGINT isn't getting all the way to PID1. When I
do the following:
kill -s SIGINT 1
It runs rc.shutdown with the argument reboot and reboots the system,
just like it's supposed to. But when I press Ctrl+Alt+Del at a virtual
terminal,
On 16/06/2015 20:40, Avery Payne wrote:
Logging generally (but not always) implies calling printf() with a
newline at some point.
What if we could come up with a simple standard that extends your
newline concept into the logging output? A newline itself may be
emitted as part of a startup
On 16/06/2015 22:32, post-sysv wrote:
Soon systemd arrives with its promise of being a unified userspace
toolkit that systems developers can supposedly just plug in and
integrate without hassle to get X, Y and Z advantages. No more
writing initscripts, no more setting policy because systemd will
On 17/06/2015 02:58, Steve Litt wrote:
What do you do if a oneshot requires that a longrun is already running?
That is exactly the problem of mixed dependencies.
The right answer is anopa (or s6-rc when it's released).
Apart from that, I don't have any more of an answer than runit or
On 13/06/2015 02:21, Steve Litt wrote:
If you had to describe daemontools, in the context of a general purpose
process manager, to a technical person, in 300 words, what things would
you say and what things would you leave out?
At this point I have to ask: are you using daemontools as a
On 13/06/2015 21:46, Steve Litt wrote:
When I write my own daemons (for use with daemontools,
daemontools-encore, runit, and soon to be S6), I use stdout to write to
the log. Wouldn't the writenewline/close interfere with that?
It's more idiomatic to actually use stderr to write to the log.
On 11/08/2015 19:50, Buck Evan wrote:
/usr/lib/libskarnet.so -lskarnet
/usr/lib/libskarnet.so: undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
Hm. For some reason my test suite doesn't catch that case, and
when trying to reproduce manually / fix my automation, I
On 10/08/2015 18:38, Buck Evan wrote:
Yes, setting --with-dynlib fixes the issue nicely.
I had set --dynlibdir and hadn't thought about needing to tell it more.
--dynlibdir is only used for the installation of what you just compiled.
--with-dynlib is used to find dependencies of what you're
On 09/08/2015 17:34, Guillermo wrote:
useful, I suppose, if you keep, say, execline's build directory intact
until the next upgrade, instead of just erasing it, and want to save
some build time in case you upgrade skalibs and want the same version
of execline to link with the new libskarnet?
On 11/08/2015 19:50, Buck Evan wrote:
/usr/lib/libskarnet.so: undefined reference to `clock_gettime'
OK, I think I nailed it, but I need to do more tests and write a
possible fix, and it's late. I'll write a detailed answer tomorrow,
follow-up to the skaware mailing-list.
--
Laurent
(Please follow-up this part of the thread to the skaware mailing-list.)
On 12/08/2015 08:37, Buck Evan wrote:
-
https://github.com/bukzor/s6-packaging/blob/dockerize/execline/debian/patches/02_link_against_libskarnet.patch
-
On 26/07/2015 04:35, Steve Litt wrote:
For all I know it might amelliorate the other problem: insane init
script complexity, by putting more of the details in the s6 run script.
I'm not sure that would be a good trade-off. An init script is run once
at boot time - or whenever you're changing
On 21/07/2015 18:36, Buck Evan wrote:
Apparently the 'private' keyword was added in 3.82, but many of the
platforms I care about have older versions of make.
Would you accept a patch to factor it out?
Short answer: probably not. Don't waste time on it. (But if you have
one already, send it
On 25/07/2015 21:43, Guillermo wrote:
I was recently looking at OpenRC's source tarball to see how it
implemented something, and was surprised by this little discovery:
Nice finding! Thanks for the experiments.
--
Laurent
On 12/07/2015 23:26, Guillermo wrote:
* Compatibility. For s6, I believe it was mentioned somewhere that it
is tested at least on FreeBSD, OpenBSD and Solaris.
Also NetBSD and Darwin (MacOS X).
As for AIX and other OSes, the important question is: do they provide
an implementation of
On 13/07/2015 22:47, Avery Payne wrote:
My Unix internals knowledge is slightly higher than zero. Perhaps a
decimal point and a digit. So this - specifically process groups -
is unfamiliar territory for me. Learn-as-I-go, and all that.
Then you definitely don't want to focus on the details
On 14/07/2015 01:27, Wayne Marshall wrote:
Huh? The documentation for perpd(8) seems as clear as possible on this:
perpd runs each child process for rc.main and rc.log in a new session
and separate process group.
Whoops, sorry, I missed that. I should have simply grepped the man page
On 09/11/2015 16:51, Casper Ti. Vector wrote:
I also considered the fifo method, but it appears that logs from
different sources might be interleaved on the character level (for
example, with `...' lines from source A and `...' lines from
source B you might end up with `aabaabbb...' in
On 12/11/2015 18:59, Jan Bramkamp wrote:
Is there a way to update /etc/s6-rc/compiled without risking a broken
system if the power fails midway through the update? The best I can
come up with is to use a symlink to a uniquely named compiled
directory and a recompile wrapper
That is exactly
Hello,
New versions of the skarnet.org packages are available, which ease
the installation dependencies.
- GNU make 4.0+ is not needed anymore. Packages will now build with
GNU make 3.81 or later.
- The skalibs package does not install a /etc/leapsecs.dat file
anymore, and packages linked
On 16/10/2015 23:11, Buck Evan wrote:
If you'll specify how you want it to look / work I'll (possibly) attempt to
provide a patch.
`s6-svstat --json` is my initial bid.
Uuuh, there's no way I'll write something that produces json.
If you have a program that can easily read json, then you
On 03/09/2015 18:25, Buck Evan wrote:
An s6-checkhelper wrapper that implements exactly the above would make me
happy enough.
Yes, that's envisionable. I'll think about it.
if a ./check exists, the framework does the polling for me.
The thing is, the command that does the polling is "sv
Hi Martin !
After some smashing things together, I took original init.c from base FreeBSD
src tree and removed parts until it's just rudimentary initialization
function that execves into execlineb boot script.
I'm interested in learning what you did: what is needed for FreeBSD to run a
The only useful things in the excerpt you quoted are:
- the initial setsid() (which can be achieved via a call to
s6-setsid in the stage 1 script)
- setlogin("root"), which is FreeBSD-specific
- the devfs test, if you want things to work even when /dev
is not mounted yet. In which case you
On 08/09/2015 13:51, Jan Bramkamp wrote:
If the script fails for any reason the service is stuck and won't
come up. Such simple scripts shouldn't fail but they might still run
into resource limits or other (temporary) problems.
If the polling script fails, it will die. The run script will
On 08/09/2015 14:10, Jan Bramkamp wrote:
How would the ./run script or more likely the daemon it exec()ed into
die from a failed child process?
The child process could s6-svc -t if it fails to find readiness, for
instance. There should be an option in the polling tool to kill the
daemon if
On 08/09/2015 10:49, Jan Bramkamp wrote:
- Have one polling daemon.
- A wrapper registers polled services with the polling daemon.
No can do, sorry.
You can't make a supervision infrastructure depend on daemons,
because daemons depend on a supervision infrastructure. The
polling daemon
On 03/09/2015 01:55, Buck Evan wrote:
That seems like a lot of brain surgery for this essential feature.
Brain surgery? That's just spawning a process running ./check up to
seven times and sending the notification newline to the right fd if
one of the invocations succeeds. That's exactly what
On 03/09/2015 12:44, Crest wrote:
Starting an unsupervised background process is a brittle workaround.
It's not a brittle workaround, it's the exact right way to do it.
You want to poll for service readiness until a certain timeout? well,
then start a process that polls for service readiness
I am unfamiliar with those. Do they all start Linux?
My goal was more to show what systemd does different from prior Linux
startups for the major distros.
I was just made aware of that article:
http://blog.darknedgy.net/technology/2015/09/05/0/
It's a pretty comprehensive list of the init
On 17/09/2015 07:21, Colin Booth wrote:
Laurent, would you consider changing s6-maximumwait to accept 0 as
"fork and wait forever"?
Sure, that's doable.
However, remember that s6-maximumtime is part of s6-portable-utils,
so you're introducing an additional dependency there.
--
Laurent
On 29/09/2015 04:46, Casper Ti. Vector wrote:
Nevertheless, I think it can be helpful to also support "opportunist"
dependencies: if said service is not enabled, it is silently ignored;
if said service is enabled, the dependency on it is considered in the
dependency resolution
On 29/09/2015 16:28, Casper Ti. Vector wrote:
as a mechanism, the online virtual is demanding to implement
in an RC system, but might be even much more difficult to implement
elsewhere. More than that, this mechanism fits naturally into an RC
system, so it is architecturally a reasonable part
On 28/09/2015 00:40, Alexander Zubkov wrote:
is I need a tool, to which I will pass number of workers I need and
program, then it will spawn given number of identical programs and
will keep them alive? I tried to google something, but may be I used
bad keywords?
I think "preforking server" is
On 28/09/2015 00:02, Jonathan de Boyne Pollard wrote:
... which according to https://news.ycombinator.com/item?id=10277123
is configured using proprietary binary blobs.
Ha. Thanks. I replied.
Normally I wouldn't bother, but FUD is so easy and spreads so fast
that I actually want to dispel it
On 28/09/2015 01:12, Alexander Zubkov wrote:
Now I'm interested just in something that is
supervising not one process, but N similar (started with the same
command) processes.
Ah, sorry, I misunderstood - it sounded like you wanted a
superserver, but with preforked children.
IIUC this time,
On 09/09/2015 18:45, Steve Litt wrote:
Several of those inits required services to be configured in XML.
Tell me one more time just so I understand: Why would *anybody*
configure their services with XML, thereby requiring the init system to
have a built in XML parser? XML parser in PID1, what
On 20/09/2015 05:44, Casper Ti. Vector wrote:
I just read your modification on the blurb page (commit e56e1294), and
found it somehow still lacking: in my experience, dependency is honoured
by OpenRC even with `rc_parallel' enabled; and more than that,
"readiness" (here defined as `exit 0' for a
On 20/09/2015 10:47, Colin Booth wrote:
specifically thus: ./up is what fires when the service is brought up,
./down is what fires when the service is brought down, ./run is what
fires when a non-running service is supposed to be running, and
./finish is when a running service stops.
On 20/09/2015 07:30, Steve Litt wrote:
Yes. The use of a file called "down" to tell the system not to run the
process, and also the use of a script called "down" to perform an
action at the appropriate time, will be holy hell to document, even if
theoretically they cannot both happen in the same
On 20/09/2015 18:26, Steve Litt wrote:
Of course, all this could be avoided the LittKit way and just run a
script depositing "down" files before running the supervisor. But the
LittKit way specifically defies Laurent's proposal that PID1 be able to
restart the supervisor (I think).
I don't
1 - 100 of 489 matches
Mail list logo
