Hello,
execline-1.3.0 will be out soon. Some changes will be made to the UI:
* The deprecated execline program will be suppressed: the only launcher will
be execlineb.
* The LASTPID and LASTEXITCODE environment variables will be replaced with !
and ?
respectively, for more consistency
Hi Vincent,
You want sysdeps, so I assume you're cross-compiling.
The easiest way for you to get sysdeps is to actually compile skalibs in
a *native* ARM environment, and fetch the sysdeps from there. If you don't
have a development environment on your real target, qemu can definitely
help :
Hi,
s6-networking-0.0.4 is out.
This release fixes a bug in s6-tcpserver-access and
s6-ipcserver-access, where user-supplied environment
was ignored.
Thanks to Vallo Kallaste for the bug-report.
http://skarnet.org/software/s6-networking/
Enjoy,
More bug-reports welcome.
--
Laurent
Hi,
s6-networking-0.0.5 is out.
(Because you always find bugs *right after* submitting a release.)
This release fixes a bug in s6-tcpserver-access which occasionally
caused improper TCPREMOTEHOST resolution.
http://skarnet.org/software/s6-networking/
Enjoy,
Bug-reports still welcome.
Hello,
skalibs-1.5.1 is out.
It fixes a build bug when cross-compiling. Thanks to Vincent De Ribou
for the report.
It also makes the default conf-cc not in debug mode, duh. .
http://skarnet.org/software/skalibs/
s6-portable-utils-1.0.3 is out.
It fixes a s6-mkfifo bug where the umask
On 04/03/2014 12:27 PM, Vallo Kallaste wrote:
Hi
I noticed that backtick -C does not work for preceding spaces, but
import -C does. Is it intentional?
-C | -c | -d | -s only make sense when backtick is performing the
substitution itself, i.e. with the -E option (which is deprecated).
Is -DEXECLINE_OLD_VARNAMES still possible when compiling execline?
If so, maybe it should be mentioned (I find the old names more
readable, and besides there are scripts that would need to be changed,
always a possible source of mayhem when the scripts perform critical
functions!)
It is
Without a conf-home file, s6-svscan requires s6-supervise in
/package/admin/s6-1.1.3.1/command/
defined in s6-config.h as S6_BINPREFIX
Why isn't it enough to find the binary in /package/admin/s6/command/ ?
(This was what I asked hours ago)
Because it's an intra-package dependency, not a
in s6-portable-utils software, why copying 'library.so/s6-memoryhog' when, I
think, It should be 'command/s6-memoryhog'.
Actually, it should be /usr/libexec/s6-memoryhog .
You must have changed conf-compile/conf-install-libexec to /library.so ; this
is wrong,
library.so is for dynamically
On 22/08/2014 23:32, John Vogel wrote:
I'm hoping this is right and also all by design
You are correct, and it is by design indeed, but not my design -
it's simply Unix.
As a very rough rule of thumb, execline blocks represent processes.
A sequence of commands in the same block will run
Hi Jorge,
Your site has superstrip.c as a single file, but I have superstrip-0.12sp,
which I think I downloaded from your site long ago. Can you clarify?
superstrip.c is indeed a single file, and it did not justify the hassle
and overhead of fully packaging - either for me or for users. So I
Hi Toki,
* Please don't send binaries to the list. If a file is too big for you
to send it, then put it on your favorite pastebin-like service and send
the URL instead.
*Contrary to what you are saying, there is no problem with libdir -
I just tried again, to make sure. When you specify
I find myself writing import VAR unexport VAR all the time
in execline scripts, because some environment variables are just
used for substitution and keeping them would only pollute the
rest of the script.
For convenience, I have added a new -u option to import and
importas. import -u VAR
On 02/01/2015 21:22, Patrick Mahoney wrote:
In skalibs, ./configure --help says:
To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE. See below for descriptions of some of the useful variables.
Though specifying CC=something seems to have no effect.
Ah,
Thanks Patrick!
--
Laurent
On 18/02/2015 14:55, Olivier Brunel wrote:
But isn't the whole anything = 128 will be reported as 128, and
anything higher is actually 128+signum also a convention that both needs
to agree upon?
Sure, but most commands exit 128 so that's reliable enough, and it's
a lot easier to follow than
On 18/02/2015 14:20, Peter Pentchev wrote:
[roam@straylight ~]$ perl -e 'die(foo!\n);'; echo $?
foo!
255
I think you should be ok, for the same reason why a shell is ok:
if you're using Perl, you're most likely writing your whole script
with it, especially control flow and error/crash
On 18/02/2015 11:58, Peter Pentchev wrote:
OK, so the not using the whole range of valid exit codes point rules
out my obvious reply - do what the shell does - exit 128 + signum.
Well the shell is happily ignoring the problem, but it doesn't mean
it has solved it. The shell reserves a few
On 18/02/2015 14:04, Olivier Brunel wrote:
I don't follow, what's wrong with using a fd?
It needs a convention between G and P. And I can't do that, because
G and P are not necessarily both execline commands. They are normal
Unix programs, and the whole point of execline is to have commands
I'm leaning more and more towards the following approach:
- child crashed: exit 128 + signal number
- child exited with 128 or more: exit 128
- else: exit the child's exit code.
Assuming normal commands never exit more than 127, that
reports the whole information to the immediate parent,
Thanks Colin !
--
Laurent
- execline: I'd like the addition of a new command, e.g. readvar, that
would allow to read the content/first line of a file into a variable.
IOW, something similar to importas (including an optional default
value), only instead of specifying an environment variable one would
give a file name to
On 05/01/2015 23:01, Paul Jarc wrote:
Is there any autoconf-equivalent processing that needs to be done to a
fresh git clone, or is it already in the same state as a released
tarball?
No processing necessary, fresh git clones should be usable as is.
Tarballs are just made from tagged git
On 07/01/2015 08:40, Paul Jarc wrote:
I'm finally digging into a long-standing bug exhibited by runwhen
(rw-match computes a timestamp 10 seconds too early), and I think the
problem is in skalibs. tai_from_sysclock() adds 10 seconds depending
on whether skalibs is configured with
On 08/01/2015 16:32, Vallo Kallaste wrote:
in 2.0.0.1
skalibs dependency bumped to 2.0.0.0
^^^ 2.1.0.0
Fixed. Thanks.
--
Laurent
On 17/03/2015 16:52, Vincent de RIBOU wrote:
Hi all,
I assume that read and write separate FDs (6 and 7) are only present as
compliancy with other tools which produce 2 real different FDs.But on TCP is
not really.
I've made TLS client over s6-tcpclient with wolfSSL. This lib takes only 1 FD
On 07/03/2015 18:37, Olivier Brunel wrote:
Hi,
I have a question regarding s6-devd: why does it set its stdin stdout
to /dev/null on start?
Hi Olivier,
The original purpose of s6-devd was actually to emulate the behaviour
of /proc/sys/kernel/hotplug, using the netlink to serialize calls
Hello,
* skalibs-2.3.2.0 is out.
It fixes bugs reported by altell.ru's static analyzer. Thanks Altell!
It also adds the gid0_scan() macro.
http://skarnet.org/software/skalibs/
git://git.skarnet.org/skalibs
* s6-2.1.3.0 is out.
It features new options to s6-envuidgid.
On 13/03/2015 15:50, Roman Khimov wrote:
11if (!w)
That one should be: if (!*w)
It's obvious that if 'w' is NULL there will be NULL pointer dereference on
line 19 or 20. What's not so obvious is how to properly fix that.
Actually, w is never supposed to be NULL. Calling
On 13/03/2015 15:24, Roman I Khimov wrote:
Hello.
Here at Altell we daily pass all of our project's software (and that is kinda
whole distribution) through special 'static analysis' build that doesn't
actually produce any output other than reports from two (currently) tools:
cppcheck and
On 13/03/2015 16:47, Roman Khimov wrote:
Both scan-build and cppcheck complain here. Sure, it's not an error, just a
harmless dead code, but well, tools don't like dead code and I personally
don't like it either, so IMO it's better to drop it if there are no valid
reasons for it to stay.
Hello,
A series of small releases.
* skalibs-2.3.3.0
---
- A bugfix in buffer_get, that returned an error on short read
instead of simply returning the number of bytes read. (For error
on short reads, buffer_getall() is where it's at.)
- A sha512 implementation,
Hello,
* execline-2.1.1.0 is out.
It adds a new command: forstdin, which splits its standard input and
spawns a program for every element.
The forbacktickx command is now a wrapper around pipeline and forstdin.
http://skarnet.org/software/execline/
git://git.skarnet.org/execline
*
I finally caved in and set up GitHub mirrors for all the
skarnet.org packages.
https://github.com/skarnet
(Yes, the picture is ugly. I may get a better one in a few
months. :P)
So, if you wanted a web interface to browse the source, here
you go. I don't like GitHub much, but if it saves me
On 25/02/2015 22:29, Patrick Mahoney wrote:
The loopwhilex keeps the pump primed, so to speak, so /service/s can
be stopped and started many times with readiness reporting working.
Otherwise, I'd need to restart /service/s/log as well as /service/s.
On the other hand, I have mostly idle
On 23/04/2015 17:41, Gorka Lertxundi wrote:
I have a very simple question, is it possible in execline to wait up to a
maximum amount of time to finish a background program execution? And if it
didn't finish, kill it forcibly?
Does this help ?
So, I've been planning to write s6-rc, a complete startup/shutdown script
system based on s6, with complete dependency management, and of course
optimal parallelization - a real init system done right.
I worked on the design, and I think I have it more or less down; and I
started coding.
On 23/04/2015 23:26, Joan Picanyol i Puig wrote:
I'd really expect a ui that can diff compiled live vs. source (and
obviously, to inspect compile live).
There will definitely be a ui to inspect compiled + live.
As for diffing the current state vs. source, I think it will be too
complex,
On 24/04/2015 13:28, Peter Pentchev wrote:
Oof, thanks a LOT for taking away the opportunity for me to advertise
http://devel.ringlet.net/sysutils/timelimit/ :P
Sorry about that. :P
It's not a very original idea anyway. busybox timeout, for instance,
does the same thing. I'm sure there are
On 25/04/2015 21:38, Colin Booth wrote:
This actually brings up another question, is there any provision for
automatic bundling? If sshd requires sshd-log and a oneshot to create a
chroot directory does s6-compile also create a bundle to represent that
relationship or do we need to define those
On 25/04/2015 11:24, Joan Picanyol i Puig wrote:
What I'd like is the ability to have some services ready-to-run, but not
up by default. Some of them might be there for contingency purposes (so
that an operator can start a failover), some of them might have to go up
(and down) at certain times
On that note, one thing you've apparently done/planned is auto-stopping,
whereas there is no such thing in anopa. This is because I always felt
like while auto-starting can be easily predictable/have expected
behavior, things aren't the same when it comes to stopping.
That is, start httpd and it
On 25/04/2015 09:35, Colin Booth wrote:
I've been having a hard time thinking about bundles the right way. At
first they seemed like first-class services along with longruns and
oneshots, but it sounds more like they are more of a shorthand to
reference a collection of atomic services than a
Since a few days ago (but I haven't tried committing anything for a
long time before that, so I'm not sure when it started) I've had
trouble pushing commits to the github mirror of my packages.
I push via git over SSH, with the dropbear SSH client, dbclient,
that reports:
dbclient: Connection
On 27/04/2015 07:59, Colin Booth wrote:
OpenSSH, at least on Linux and *BSD, chroots into an empty directory
after forking for your login. That was an example but I think the
question is still valid: if you have a logical grouping of longrun foo,
longrun foo-log, and a oneshot helper bar, where
Ah, good catch. Patch applied, thanks. It's available in the
current git.
Note that I still can't push to github because they've broken
their sshd's compatibility with dropbear. I've reported the
issue, but it hasn't been fixed yet. Until they fix it, the
GitHub mirror for skarnet.org packages
On 11/05/2015 13:52, Scott Mebberson wrote:
I'm working on an addition to the s6-overlay project. I want to make it
super easy to create environment variables within a Docker container.
IIRC, /var/run/s6/container_environment is meant to hold the variables
that the container is actually
Hello,
Just a few small releases to keep you waiting until s6-rc is ready. :P
skalibs-2.3.4.0
---
Cleanups and bugfixes. New stat_at() and lstat_at() functions.
http://skarnet.org/software/skalibs/
git://git.skarnet.org/skalibs
execline-2.1.2.0
New
On 10/05/2015 00:07, Guillermo wrote:
I ran into this while experimenting with the example / template stage
1 and 3 init scripts that come with s6's source code. Both of them do
an early fdclose 0 to ignore input. Wouldn't that be tempting the
demons to fly through your nose, then? :)
Know
On 10/05/2015 20:14, Guillermo wrote:
I mostly followed the example init scripts, but I did deviate, among
other things to delegate tasks to OpenRC (as a bundle of oneshot
services in s6-rc terminology, hehe). And now that you remind me they
were originally there, I don't have the fdclose 1 and
On 09/05/2015 01:13, Guillermo wrote:
Are we not supposed to use pipeline or forbacktickx with a closed
stdin, or is this something that needs fixing?
Honestly... both. It's Complicated (tm).
I read your mail yesterday, shortly after you wrote it, but it
opened a rabbit hole in more than
On 08/06/2015 12:21, Vallo Kallaste wrote:
The leapsecs.dat from skalibs-2.3.5.0.tar.gz matches with old leapsecs.dat
file on the three old systems I tried. Has it been updated?
Has it been 3 years already ? My, how time flies. Or leaps.
Sorry, I completely missed the new leap second
On 09/06/2015 20:17, Olivier Brunel wrote:
+ if (pids.s) sig_block(SIGCHLD) ;
(...)
+sig_unblock(SIGCHLD) ;
Gah. Of course that's it - the noob mistake of looping around fork() without
blocking SIGCHLD. That's so, so bad - I'm really ashamed. :(
That's what happens when you
On 09/06/2015 23:09, Amin Rasooli wrote:
For the past few days I have been banning my head to the wall to figure how to
install runit on oracle linux.
Could someone give me a working repository ? (all the ones in internet seem to
be unavailable)
Hi Amin,
Wrong list! I didn't write runit.
On 09/06/2015 23:37, Amin Rasooli wrote:
Sorry for emailing the wrong mailing list, do you happen to have a
repository that I can add ? the tar installation, doesn’t seem to be
working for me.
That's weird. You may want to report a bug to Gerrit or to the
supervision mailing-list, with the
On 2015-06-19 19:19, Les Aker wrote:
Looks like s6-linux-init 0.0.1.0 pulls s6 in as a build-time
dependency. Not a huge issue, but might be worth updating the docs to
clarify that until the next release removes that? I've learned to
trust your docs and build tools enough that I spent a while
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
On 25/06/2015 20:16, Les Aker wrote:
I'm not sure if this is intentional given your latest update, but it
looks like the GitHub mirrors for s6 and s6-linux-init don't have then
new versions.
Because I forgot to tag them. Fixed now. :)
However, don't grab those - better versions are coming
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 16:06, Roman I Khimov wrote:
It was noted that with no servers in resolv.conf s6-dns always leaks an fd
after s6dns_resolve_parse_g() usage. I wasn't able to trace it deeper, but
always cleaning up in s6dns_resolve_parse() won't hurt.
Thanks for the report!
However, this isn't
On 14/06/2015 21:57, Olivier Brunel wrote:
That is, in your test now you're using x[1] even though it might not
have been used in the iopause call before, so while I guess this isn't
random memory, it doesn't really feel right either.
You're right, of course, that's why the else was there in
On 14/06/2015 14:37, Olivier Brunel wrote:
Because of the buffered IO, the possible scenario could occur:
- netlink uevents (plural) occur, i.e. data ready on stdin
- iopause triggered, handle_stdin() called. The first uevent is processed, child
launched, we're waiting for a signal
- SIGCHLD
Hello,
s6-2.1.4.0 is out. It features:
- Direct readiness notification support in s6-supervise (and consequently
deprecation of the s6-notifywhenup binary).
- Optimization of the service respawn delay by s6-supervise: the
security delay is now one second between two successive ./run
On 18/06/2015 05:12, Guillermo wrote:
I did a quick run and found out that in generated execline scripts
except the stage 1 init, the shebang line starts with #!execlineb.
Yes (unless you use slashpackage).
And on the machines where I tested, it's not a problem as long as
execlineb is in the
Hello,
s6-linux-init-0.0.1.0 is out.
It is a new package that, for now, only contains one program,
and more documentation than source code. :)
Its goal is to automate the creation of stage 1 (/sbin/init) binaries
for people who want to run s6-svscan as process 1.
Unfortunately, it has to
On 16/06/2015 04:47, Guillermo wrote:
In the examples/ROOT/img/services-local/syslogd-linux subdirectory,
there is an implementation of the syslogd service for Linux , using
s6-ipcserver with the -1 option and s6-notifywhenup for readiness
notification. Maybe you could modify it in the s6 git
When you use s6-notifywhenup, or any readiness notification helper
that is not the service's direct supervisor, there is still a small
race condition - which can only bite in a very, very pathological
case, when the stars align in an incredibly evil way and your
system's scheduler decides that
On 06/07/2015 12:13, Laurent Bercot wrote:
may not find it without the proper --with-libdir option.
I meant --with-lib, of course.
--
Laurent
Hi Claes !
For me execline fails to build from source because -lskarnet is listed
as a dependency instead of in EXTRA_LIBS. Is this on purpose?
Yes, this is intentional. EXTRA_LIBS is only used for things like
-lrt or -lsocket which are needed for some binaries on some systems
(and I
On 06/07/2015 14:07, Claes Wallin (韋嘉誠) wrote:
./configure: error: target x86_64-unknown-linux-gnu does not match the
contents of
/gnu/store/hynkavlnn6j0x6aifrawx9d27j6vmzb1-skalibs-2.3.5.1/lib/skalibs/sysdeps/target
Weird. What's the content of
Interesting, never heard of this make feature before. Does that only
work with static libs? Because the .so is in the search path.
It's supposed to work with both static and shared libs.
The defaults for skarnet.org package installations specify *different*
directories for static libraries
Hi,
Guillermo reported a bug discovered here:
https://bugs.gentoo.org/show_bug.cgi?id=541092
The latest git versions of skarnet.org packages should fix
the issue (with the wonderful magic of XYZZY!), so the
Gentoo workaround should now be unnecessary.
The latest versions also rework how
Should be all fixed, thanks!
--
Laurent
On 22/08/2015 08:26, Colin Booth wrote:
I run my s6 stuff in slashpackage configuration so I missed the
s6-fdholder-filler issue. The slashpackage puts full paths in for all
generated run scripts so I'm a little surprised it isn't doing that
for standard FHS layouts.
FHS doesn't guarantee
On 21/08/2015 22:05, Buck Evan wrote:
Is there any kind of test suite for skalibs/execline/s6 ?
I would love it if there were one. :)
See
http://skarnet.org/cgi-bin/archive.cgi?1:mss:276:201502:mndjpngghogjemeljjac
and the ensuing thread, also available at
On 21/08/2015 22:10, Buck Evan wrote:
@Laurent: What's your take on man pages?
Short version: I like them, as long as I don't have to write them
or move a finger to generate them.
Long version:
I honestly believe man pages are obsolete. They were cool in the
90's when they were all we
On 20/08/2015 16:43, Colin Booth wrote:
Yeah, this is for the special case where you have a daemon that
doesn't do readiness notification but also has a non-trivial amount of
initialization work before it starts. For most things doing the below
talked about oneshot/longrun split is best, but
On 20/08/2015 10:57, Laurent Bercot wrote:
s6-svc: warning: /run/s6/rc/scandir/s6rc-fdholder/notification-fdpost
addition of notification-fd
Looks like a missing/wrong string terminator. Thanks for the report,
I'll look for it.
I can't grep the word addition in my current git, either s6
On 28/07/2015 16:59, Patrick Mahoney wrote:
If I understand correctly, any 'readiness' reporting mechanism must originate
from the run script (to inherit notification-fd).
Yes.
Do you have any suggestions for adding readiness support to a daemon *without
modifying that daemon*?
It's
On 09/08/2015 09:27, Colin Booth wrote:
I haven't yet dug into the skalibs code to see what changed between
those tags, or started bisecting it to find out which commit broke.
The git diff between 2.3.5.1 and current HEAD is pretty small, and
there's really nothing that changed in the graph
On 13/08/2015 19:55, Colin Booth wrote:
Makes sense. In this case can we get a --livedir=DIR buildtime option
so us suckers using a noexec-mounted /run can relocate things easily
without having to type -l livepath every time we want to interact
with s6-rc?
Unless I encounter a strong reason
Oh, and btw, I'll have to change s6-rc-init and go back to the
the directory must not exist model, and you won't be able to
use a tmpfs as live directory - you'll have to use a subdirectory
of your tmpfs.
The reason: as it is now, it's too hard to handle all the failure
cases when updating
On 13/08/2015 18:05, Laurent Bercot wrote:
If you're going to pull from git head, then you should pull from
the git head of *every* project, including dependencies. Which you
didn't for execline. :)
I'm not lying! I'm just chronologically challenged sometimes. See,
if you had pulled from
On 14/08/2015 01:25, Colin Booth wrote:
I'm not sure how I feel about having the indestructibility guarantee
residing in a service that isn't the root of the supervision tree. I
haven't done much with s6-fdholderd but unless there's some extra
magic going on in s6rc-fdholderd, if it goes down it
On 12/08/2015 04:45, Guillermo wrote:
I don't know about syslog on /dev/log, but for syslog over a network
there is this:
Yeah, I know about the syslog RFCs. The mild way to put it is that
they're about as useful, well-engineered and enticing as a steaming
pile of donkey shit. And donkey shit
(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
-
Hello,
skalibs-2.3.6.0 is out.
A couple bugfixes (including a possible crash in socket_local46)
and a new openreadnclose_nb() function.
http://skarnet.org/software/skalibs/
git://git.skarnet.org/skalibs
execline-2.1.3.0 is out.
A new configure option, --shebangdir, to specify the
On 16/07/2015 19:22, Colin Booth wrote:
You're right, ./run is up, and being in ./finish doesn't count as up.
At work we use a lot of runit and have a lot more services that do
cleanup in their ./finish scripts so I'm more used to the runit
handling of down statuses (up for ./run, finish for
On 17/07/2015 09:26, Rafal Bisingier wrote:
So I run them as a service with sleep BIG in
finish script (it's usually unimportant if this runs on same hours
every day). I can have this sleep in the main process itself, but it
isn't really it's job
I also use a supervision infrastructure as a
On 19/07/2015 20:13, Guillermo wrote:
Well, I haven't been very lucky with oneshots. First, the #!execline
shebang with no absolute path doesn't work on my system, even if the
execlineb program can be found via the PATH environment variable.
Neither does #!bash, #!python, or any similar
On 13/07/2015 17:35, Colin Booth wrote:
Those options are all bad. My workaround was to mount a new tmpfs
inside of run (that wasn't noexec) but that made using s6-rc annoying
due to the no directory requirement. I don't think there's anything
inherently bad about nesting mounts in this way
On 23/10/2015 00:57, Guillermo wrote:
So, I don't know if the handler scripts for diverted signals that the
new version of s6-linux-init-maker generates are intended to be
compatible with BusyBox. But if that's the intention, then the ones
for SIGUSR1 and SIGUSR2 are inverted: I think that the
On 14/10/2015 02:58, Buck Evan wrote:
The packaging system I'm targeting (pypi wheels =X) are built binaries that
are relocated arbitrarily, so the "run-time installation path" is entirely
unknown at compile time.
I don't understand. How is that even supposed to work? If packages
want to
On 20/10/2015 02:16, Buck Evan wrote:
My canonical slowly-printing example is:
yes hello world | pv -qL 10 | tai64n
Under daemontools classic you'll see the output gradually appear character
by character, with timestamps.
Under s6, this seems to hang and I ctrl-c it. I'm sure if I waited
On 20/10/2015 23:36, Buck Evan wrote:
Is it expected that it's line-buffered?
It's not line-buffered. It's optimally buffered, i.e. the buffer
is flushed whenever it's full (obviously) or whenever the loop
goes back to reading with a chance of blocking. When you test
with a loop around echo,
On 13/09/2015 09:08, Colin Booth wrote:
I've been digging into managing a system completely under s6 and I
can't seem to find the right time to run `s6-rc -da change'. Run it
before sending s6-svscan the shutdown/reboot/halt commands and can end
up with a situation where your read/write drive
On 13/09/2015 20:25, Colin Booth wrote:
My current issue is that I'm initially remounting my root filesystem
as r/w as one of the first steps for s6-rc, which means that if I'm
doing everything correctly, s6-rc attempts to remount root as
read-only as part of its shutdown.
Yeah, indeed, that
On 15/09/2015 00:40, Colin Booth wrote:
Ok, did some more testing and it looks like the contents of $SVCDIR
end up being the additive delta between current and new. When
initializing, there are no s6-rc managed servoces in $SVCDIR so of
course the delta will be all new services. When adding a
On 29/09/2015 00:08, Buck Evan wrote:
If it's not good for s6, I'm not sure it's good for my framework either.
Not necessarily. s6-supervise is extremely paranoid; depending on its
use cases, your framework doesn't have to be. Also, if you control both
ends of a named pipe and can reasonably
On 29/09/2015 00:15, Olivier Brunel wrote:
[2] https://github.com/jjk-jacky/anopa/blob/master/src/utils/aa-setready.c
Yeah, the problem is, aa-setready is prone to the same race condition as
s6-notifywhenup was, which is the reason why I scrapped s6-notifywhenup and
made a fd to report to
1 - 100 of 527 matches
Mail list logo
