I don't understand what you mean by that; $foo/${foo} in $newfiles won't
expand because multisubstitute is being used to expand both $foo and
$newfiles.
Oh. Yes, of course. I was wrong about that, sorry.
That's an interesting workaround indeed, but it still feels like a
workaround, and I'd
But that is wrong; you are assuming that cmdA does not create/deletes
files; I don't think it is that unreasonable to want to use the same
list of files for two commands instead of expanding *.c twice that
results in different values.
I don't understand. The globbing happens at elglob
To prevent literal "$y"s or "${y}"s in the value of VARA ($x) from
expanding, you must replace the second expansion command with a
multisubstitute, and give the variable that was declared before
multisubsitete another name using define
I would argue the opposite, i.e. that parallel
Applied (with tiny fixes), thanks!
Note that libenvexec is now separate from libstddjb (which has a
tendency to grow much bigger than the other subdirectories). As the
separation between subsystems of skalibs is purely "administrative"
(vaguely thematical but there are cross-references
Maybe something like Zig's SegmentedList[1] would fit?
Something like "stop trying to be too smart and just use malloc" fits
perfectly ;)
(I normally wouldn't do this, but the ftrigio structure already
includes a ftrig1_t, a stralloc and a regex_t, all of which call
malloc, so the trade-off
If a single s6-ftrigrd is requested to listen on many listeners, the
genalloc_readyplus may have to move the ftrigio's to a new memory area,
causing the char* inside their buffer to get outdated, overwriting
unrelated memory areas when filling the buffers and possibly triggering
a SIGSEGV.
-- Original Message --
From "Carlos Eduardo"
To supervis...@list.skarnet.org
Cc "Carlos Eduardo"
Date 2024-05-04 21:58:21
Subject [PATCH] Add adoption to trap
With this patch, trap(1) is able to accept an existing PID as prog...,
if given the new -P option.
I'm sending this as
To complete my previous answer, I update the minor (the third number)
when new symbols are added. So the ABI changes, but no rebuild is
necessary because the old symbols are still there (with the same
signature and semantics).
However, new versions of software such as s6, including bugfix
While we're at it, may I ask about s6's versioning scheme? I noticed
there was an ABI change in skalibs (env_mergen becoming a macro), but
the Gentoo package for skalibs is currently set up to only trigger
rebuilds of dependant packages if the second number changes (e.g. from
2.14.x to 2.15.x).
The cause for this is the weird dance we have to do with fifodirs and
fifo permissions in order to grant the correct filesystem rights
The model was actually correct, it was just a bug, that nobody
noticed because it's rare that root has to wait for a notification
from user-owned services.
I have a setup where sometimes a root process will s6-svwait on a
s6-supervise that is running as another UID.
Unless I s6-applyuidgid -u $svscan_uid s6-svwait ..., the svwait never
returns and the pipe it creates just stands there in the event/ folder
until I `sudo rm` it.
If it helps, the
That was... the best possible answer to my ribbing :D
Applied, thanks!
--
Laurent
I'm disappointed, I thought that mail contained a patch that would
fix the lack of unix-transactional.h documentation! :)
--
Laurent
Hey. Thanks for your work.
If you're looking for a more community-oriented hosting service
than GitHub, you could try Codeberg (https://codeberg.org) or
Sourcehut (https://sr.ht/). But it's all up to you.
--
Laurent
1. example/s6/httpd-4/run script. In this script, it use 's6-tcpserver -v2 -1
-U -c 512 -- $ip 80’, but -v2 is not
a valid options for s6-tcpserver. After change -v2 to -v, s6-tcpserver works.
Whoops, I'll change that, thanks.
2. example/s6/httpd-4/log/run script. Here the problem is
Fixed, thanks!
(I assume you meant in the s6 package. :))
--
Laurent
Thank you! Sorry for the rather bare initial report - was very much
one of trying to work out what had gone wrong initially!
It's all good - I'm supposed to catch these things and I failed,
so the next best thing is to get them fixed as quickly as possible :)
--
Laurent
I can confirm that the patch worked:
Thanks, execline-2.9.5.1 is out now.
--
Laurent
Running backtick with gdb reveals that the crash is caused by the
`memcpy' at line 63 of src/libexecline/el_modifs_and_exec.c
Thanks for doing my work for me :D
(these are the bugs I usually catch before release, but, laziness.)
The latest execline git head should fix it. If it works for
backtick -E A_LONGISH_NAME { s6-echo foo }
It fails with:
Huh. I must have missed something. Thanks for the report, will
investigate and fix.
--
Laurent
Hello,
New versions of some skarnet.org packages are available.
A very light update this time, just keeping the lights on.
skalibs-2.14.1.1(release)
execline-2.9.5.0(minor)
s6-2.12.0.4 (release)
tipidee-0.0.4.0 (minor)
skalibs and s6 get tiny bugfixes.
I would like to package an example service for s6. Could you suggest one?
tipidee would be a good one. I plan to release tipidee-0.4.0.0 very
soon
and have an Alpine package for it early next week, if you want to have
example scripts.
So, is s6-rc a good candidate for rpm package? I am
1. Run btmpd, utmpd, wtmpd as s6 service. But this option will add s6 as extra
dependency.
2. Run btmpd, utmpd, wtmpd as systemd service. The dependency is minimal. Only
depends on s6-ipcserver.
On Alpine, s6-ipcserver is in a separate package because Alpine is very
careful about disk
Please note that this list isn't meant for real-time debugging.
If you want real-time help, please join IRC (#s6 on OFTC), that's what
it is for.
Apr 10 22:06:53 rpm-builder s6.systemd-boot[15235]: s6-supervise s6-svscan-log:
warning: unable to spawn ./run (waiting 60 seconds): No such
I prefer this way. Some packages prefer s6 as their process supervisor,
some
packages prefer systemd. With the help of s6 rpm package, other rpm
packages
who depend on s6 can install their service in s6’s service directory.
We just pave
for the community, the choice is in their hands.
Since your s6-svscan doesn't run as pid 1, you don't need a finish or a
crash script. Not creating the .s6-svscan directory at all is good: the
default behaviour is suitable for running s6-svscan as a normal service.
The answer to the rest of your questions implies policy decisions. In
other
I notice s6-svscanboot is the start script for s6-svscan. I am not an execline
expert, but I can see that s6-svscanboot prepare log directories and start
s6-svscan. If systemd provides log service for s6-svscan. Do we need
s6-svscanboot for rpm package?
No, you don't.
As I said in a
One last question: do we need the s6-openrc rpm package? I know systemd is more
popular for Redhat and Fedora. Any suggestion?
I doubt anyone is going to run openrc on Fedora. If you're going to
package
s6 for a given distribution, you should integrate it properly with that
distribution,
RHEL and Fedora have an alternatives system:
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
* https://www.linux.org/docs/man8/alternatives.html
Then it looks like the correct way to proceed, if Eric can coordinate
with
the maintainers of the filesystem and bash
There have been some discussions, starting at Fedora, about unifying
the bin and sbin directories:
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
Ha. 25 years later, they understand that the separation makes no sense,
and *just* when we were going to use that silly separation to
2) The presence of a notification-fd file tells s6 that dbus-daemon
can be somehow coerced into producing an s6-style readiness
notification using file descriptor 3 without changing its code, are
you sure that's the case with this script? My service definition for
the system-wide message bus
After check the installed package of execline on alpine. I choose to
install main part of execline to /usr/bin.
Create /usr/sbin directory, create relative symbol link for cd, umask
and wait to /usr/bin/execline.
Does that mean you're using --enable-multicall? You can, it's just
And yes, since execline-provided cd, umask and wait, when called via a
PATH search (not that a shell will ever do that, but execvp() can), will
substitute themselves to Fedora-provided POSIX binaries, it is necessary
to build execline with --enable-pedantic-posix in order to prevent
trouble
[packager@rpm-builder etc]$ env | grep PATH
PATH=/home/packager/.local/bin:/home/packager/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I guess /user/local/bin or /usr/local/sbin is our first choice? Do we need
--enable-pedantic-posix for /usr/local/bin or /usr/local/sbin?
In my (admittedly ugly) package, I simply delete execline's `cd' and
`umask'; `wait' is renamed to `execline-wait', just like `execline-cd'
and `execline-umask' (which are not conflicting and so not deleted).
This means that your execline package cannot run execline scripts that
use cd, umask
file /usr/bin from install of execline-2.9.4.0-1.fc39.x86_64 conflicts
with file from package filesystem-3.18-6.fc39.x86_64
file /usr/bin/cd from install of execline-2.9.4.0-1.fc39.x86_64
conflicts with file from package bash-5.2.26-1.fc39.x86_64
file /usr/bin/umask from
Yes, skalibs, execline are different projects. The GitHub site is just a
central and temporary place to hold the spec files.
For skalibs project, I build 4 rpm packages: skalibs, skalibs-devel,
skalibs-devel-static, skalibs-doc.
skalibs-devel depends on skalibs. Just follow the aports
I haven't looked in detail, but I'm not sure why you want everything
in one single RPM.
skalibs, utmps, execline and s6 are different projects. A package
should
be one project, not a set of projects. A package manager will handle
dependencies between packages and install all the rpms that
my first question is: does skalibs support glibc? alpine only support
musl.
Yes. skalibs supports everything that makes a good attempt to be
POSIX-conformant, so that includes glibc.
--
Laurent
Hi Wang,
Your e-mail client seems to be broken. It sends HTML entities as
text/plain,
and it makes the content of your mail unreadable. Please fix this, if
you can.
From what I can understand, you're looking for rpm packages for skalibs
and utmps. I don't know if there are any; I
there is no version information option (like say "-V") for
the s6 utils. such a command line option should make the
tool output its version number and terminate.
it would be nice if such an option could be added to the tools.
It would also add boilerplate to every single binary, which would
Additionally, the shibari documentation has been ported:
* https://git.sr.ht/~flexibeast/shibari-man-pages/refs/v0.0.1.0.1
(For those wondering, porting the two man pages for shibari took me roughly an
hour.)
You are awesome.
The difference in UDP is that not having a connection makes it harder to model
with the stdin/stdout method of UCSPI, right?
Yes. A super-server model makes sense for TCP because you can spawn
one server to handle one stream; not so much for UDP, because there is
no stream, only packets,
Hello,
New versions of some skarnet.org packages are available.
This is mostly a bugfix release, with some new features.
skalibs-2.14.1.0 (minor)
s6-2.12.0.3(release)
s6-dns-2.3.7.1 (release)
s6-networking-2.7.0.1 (release)
tipidee-0.0.3.0(minor)
Yes, it can be done with current execline tools through options like
-s in define and importas, but I feel something like this would be
clearer:
block-define var { 1 2 3 }
printf "%s\n" "This is ${var}"
Does this already exist?
Not really, but that sounds like a possible addition, the model
I've been trying to find out why my "finish" script is not working
(or perhaps it is working but not printing output anywhere I can see)
The ways of shutdown are mysterious. :)
However, I don't think kill(-1, n) *works* for pid 1.
Indeed, it does not. That kill is supposed to be sent to
Hello,
I don't normally spam all of you for bugfix releases, but this one is
important. You definitely want to grab the 2.12.0.2 version of s6, not
the 2.12.0.1 one. The bug could prevent a shutdown from completing.
https://skarnet.org/software/s6/
git://git.skarnet.org/s6
Sorry about
Hello,
New versions of some skarnet.org packages are available.
This is mostly a bugfix release, addressing the problems that were
reported since the big release two weeks ago.
Despite that, s6-dns got a minor version bump because the fixes
needed an additional interface; and
Minor issue, the version linked from the web page
(https://skarnet.org/software/skalibs/) needs a bump
Whoops. Fixed.
--
Laurent
Hi Vincent,
I'm not sure if you're testing with the released version of tipidee
or not. Please make sure to only report bugs against the released
version or the git head.
In any case, the absence of a port in the Host field is certainly not
the reason why tipidee would answer a 400. There
Hello,
New versions of all the skarnet.org packages are available.
This is a big one, fixing a lot of small bugs, optimizing a lot behind
the scenes, adding some functionality. Some major version bumps were
necessary, which means compatibility with previous versions is not
guaranteed;
Fixed in latest s6-networking git head. It was an invocation of
tls_error() with the wrong context.
When run with the fixed version, s6-tlsd-io prints this error:
s6-tlsd-io: fatal: unable to tls_configure: failed to read private key
which means there's an issue with your fd.key file,
The release date of tipidee is approaching.
Since the last announcement, there have been some significant changes
to tipidee, including:
- a more flexible logging configuration
- custom error pages (by domain)
- custom headers
as well as many bugfixes, thanks to everyone's reports.
Just tried with latest s6-networking HEAD (and deps) and also libressl
3.7.3.
Unfortunately same issue.
I hope it was not due to my certs. Those are generated with openssl 3rd
book (self signed certs).
LibreSSL hardcodes its list of trusted anchors so it won't be able to
*verify*
It turns out there is this Linux specific syscall (prctl(PR_SET_PDEATHSIG,
signal)) to set the saner behavior of actually being informed if your parent
dies and react to it so s6 is able to bring service back up, but it’s opt-in.
Is there any tool in the s6 ecosystem or otherwise that I can
I used Libressl 3.8.1 with all official releases (skalibs, execline,
s6, s6-networking, s6-dns and s6-portable-utils).
Except for tipidee with skalibs all on HEAD.
Thanks.
I cannot reproduce the crash with the s6-networking git head. Can you
please test with it? (Even if there's a bug in
In that situation it produces a SIGSEGV during s6-tlsd-io execution.In
attachment 2 strace log outputs (pid 14138 for the caller of s6-tlsd-io, pid
14141 for s6-tlsd-io itself).
Why this s6-tlsd-io is always crashing (some credential/Id's)?
It's a libtls crash during the preparation of
- is it possible to customise error pages as static pages? Currently I
think not but is it forecasted?
I initially wanted to *specifically* avoid this, because some Web
servers
return a 200 status when serving their customized error page, which is
a terrible idea. But then I realized you
An mdoc(7) port of the documentation is now also available:
https://sr.ht/~flexibeast/tipidee-man-pages/
Thanks a lot - what speed! :D
But please be aware that everything can still be very much in flux
until the official release. Doc is getting fixed, completed,
reworded, as much as code is.
Hi folks,
For those who don't know, I've been working on a very normal, very sane
project, not rabbit-holey or scope-creepy *at all*: a web server.
It's named tipidee, and I just made the switch - it is now serving
the skarnet.org site.
It's in a good enough place that I can now declare
$ cat conf-cc
/opt/bin/musl-gcc -static -Os -march=x86-64 -fomit-frame-pointer -pipe
-Wall -Wno-trampolines -Wno-maybe-uninitialized -Werror=overflow
-mpreferred-stack-boundary=4 -falign-functions=1 -falign-jumps=1
-falign-loops=1 -fno-unwind-tables -fdata-sections -ffunction-sections
While following the guide for the init part I noticed the init scripts seem to
be shell scripts. Is there any particular reason they are not execline scripts?
I’ve become much more fond of those while trying the waters before.
Would it be sensible for me to rewrite them in execline? And,
The -Y flag was being treated as if it means the default of not asking
for a client cert.
Thanks! Applied with a slightly different style.
I should really have used a different name for the optional client
certificate. As is, -Y/-y is asymmetrical between s6-tlsc and s6-tlsd,
and that's ugly
This can be even worse than that: the timestamp from a GPS source can take
several tens of seconds to stabilize, depending on the accuracy of your GPS
system and available satellites. Until then, the system date can jump back and
forth around the actual time.
Ew. That's pretty bad indeed.
I am setuping s6 for managing services on mine Linux embedded system.
Everything is fine. But I faced issue related to system datetime change.
My system does not have RTC, but it has GNSS module (managed by gpsd).
After GNSS get the location and time chronyd service update system time.
And
-*=*) eval "$arg" ;;
+*=*) eval "${arg%%=*}=\${arg#*=}" ;;
I'm going to check, but that's probably correct. Thanks!
--
Laurent
Actually I mean a *directory* that is guaranteed to exist (and meanwhile
unexecutable): so /dev here.
Indeed, /dev should work; but using it still makes me queasier than
crafting a nonexistent path. The mkstemp thing works, so, not going to
change it to save a couple of syscalls in a configure
Fixes pushed to git, thanks!
When given an unexecutable path, child_spawn() returns 0, but errno
is unset... that's on purpose. Unfortunately, in the parent there is
no way to know the child's execve() error code; all we have is the
exit status, 127, and we cannot report the reason for the
I pushed a workaround to the skalibs git.
Could you please try a build on a machine that exhibits the early
return behaviour and tell me if
- the behaviour is correctly detected by ./configure (the last sysdep)
- the child_spawn*() family of functions now works properly even on
this
Actually I copied the fragment of posix_spawn(3) from a Devuan Chimaera
machine, so the problem may be not specific to CentOS 7. I did not test
CentOS 6 or other distro (version)s, for example; but on Rocky Linux 8,
which I unfortunately also need to support at work, the behaviour is
as
Testing the behaviour may be challenging, however, because I suspect
the CentOS 7 implementation of posix_spawn() is just racy, and they
simply documented that they don't care.
Thinking about it more, I'm afraid it's not a testable behaviour.
Not only isn't there any way to force the race
As a more general fix, I think tryposixspawn.c should at least try
spawning a probably unexecutable path (like the one above) as well,
which corrects the sysdep on systems where the expected conformance
is broken.
Adding a sysdep to detect that case is a good idea indeed!
Rather than
* In `trap.html', there is a reference to the removed `timeout' keyword.
Fixed.
* In `s6-svscan-not-1.html', the systemd unit (traumatic experience with
it, as you may easily expect) lacks a `KillMode = process'.
I believe the correct setting is actually KillMode=mixed; and the
What's happening is that utmps-utmpd only checks the value of the
*primary* gid of the client. It does not check supplementary groups.
I agree that it's counter-intuitive, and will see I can fix that.
Unfortunately, no, that's not fixable. The credentials-passing
mechanism used by
Please avoid using a HTML client, it looks like your converter is
buggy and giving some garbled output (your top output is unreadable).
What's happening is that utmps-utmpd only checks the value of the
*primary* gid of the client. It does not check supplementary groups.
I agree that it's
Thanks for the kind words, Oli :)
It's all fine, really. In all fairness, yes, I *was* a little cheeky,
because Esben sounded very dramatic about a harmless warning.
But there's a legitimate UX takeaway here: the warning is indeed
needlessly scary. So it will be changed in the next s6-l-i
I think it would be fair to be able to configure s6-linux-init so that
it does not rely on specific details about what hardware is available.
Then I have some good news for you: s6-linux-init already does not
rely on specific details about what hardware is available.
Because if it did,
I checked the shadow utils site. It's provide a lastlog CLI. while it's a lack
of lastlogd similar to utmpd/wtmpd.
The lastlog file isn't managed by utmp, but by the login program, with
or without assistance from PAM. It's an entirely different operation,
and I don't understand why you'd want
While that might make sense when the system is expected to have a
/dev/tty0 device, it is kind of messy to see that on systems that is not
supposed to have /dev/tty0.
Kernels and various parts of init systems print warning messages all
the time for similar reasons (some operation failed
is there any plan to support lastlog in utmps project?
lastlog uses a separate /var/log/lastlog file, so it's not directly
tied to utmp. If anything, it *uses* utmp, so it's the other way around:
the shadow-utils package should support utmps.
--
Laurent
And the timeout is only going to start during exit, right?
Naturally. :)
--
Laurent
While that would make s6-log nicer to integrate with s6-rc, I still
think that the current behavior of potentially blocking SIGTERM forever
is undesirable, so some kind of timeout in s6-log could still be a good
idea.
That's why I was suggesting a timeout. And since logging a partial line
as a
The goal is to never write partial lines. So if the process is sent a
signal to exit while a partial line have been received, simply exit
without writing anything to file.
One of the goals is not to write a partial line if it can be avoided;
but it defers to the more important goal of not
How are you thinking changes to termination behaviour will interact with the
existing -p option?
There would be no specific interaction.
-p only makes s6-log ignore SIGTERM. The signal is received, but does
nothing.
The new timeout option would make it wait on receipt of an exit signal,
be
The problem is that until a new-line is received, s6-log will not
respond to SIGHUP and SIGTERM. I assume this is not as expected.
This is expected; the goal is to finish reading partial lines
before existing. This is useful with services that are writing a
large amount of logs, where the
An mdoc(7) port of the documentation for s6-linux-init is now available:
https://git.sr.ht/~flexibeast/s6-linux-init-man-pages/archive/v1.1.1.0.1.tar.gz
拾
An mdoc(7) port of the documentation for s6-rc is now available:
That's awesome, thanks a lot Alexis! 拾
--
Laurent
Hello,
New versions of some skarnet.org packages are available. They fix a few
visible bugs, so users are encouraged to upgrade.
I usually do not announce bugfix releases. This e-mail is sent because
two new functionalities were also in git when the bugfixes needed to be
made, so they're
Sending signals to the trap process does nothing. If I revert
9d55d49dad0f4cb90e6ff2f9b1c3bc46a6fcf05f, trap works as expected. After
some debugging I think that the pids array in trap.c contains garbage
since it isn't initialized statically anymore (see the attached patch).
Your diagnosis is
I'm going to regret this.
ifthenelse -s { eltest -f ${FILE} } { export EXISTS ${FILE} } { }
env
This construct is purposefully not documented, because it breaks
syntactic and logic assumptions that are true in the rest of execline.
But it can simplify your life in a handful of cases, like
Can you please tell me what locale you're using, for testing purposes ?
--
Laurent
reset LC_ALL to avoid locale dependent sorting.
This is critical to ensure bsort() works reliably.
In my locale "execline-cd" was sorted after "execlineb"
... lol. Changing the sorting order for ASCII characters is probably the
most insane misdesign in locales. Good catch!
Thanks for the
Hello,
New versions of some skarnet.org packages are available. It hasn't been
long since the last release, but lots of small things have happened and
it doesn't make much sense to let them rot in git.
The main addition is a new multicall configuration for the execline,
s6-portable-utils
Am I missing something?
Sorry, I had failed to push the changes. Fixed now.
On s6-instance-update, as a user I'd expect it to exist and be run
automatically as part of s6-rc-update. Since restarting applies the
new definition for longruns, having to do one extra step (or two if
s6-instance-update isn't made) per instance of a templated longrun
would be
Yes, this is only possible because you did a very good job in the first
place. Good work! This cannot be said enough.
Thanks.
I managed to de-global the arrays in trap.c, so now the only
unavoidable
global is in forstdin: a pointer to a structure accessed by a signal
handler.
You'd think
allow you to link against a dynamic libexecline. Can you do it, see
how much space you gain? That's a configuration I would definitely
support, even if it's slower - people usually love shared libraries.
I'm tired. This configuration is obviously already supported, and no
need to patch. You
Look, here's a trivial, suboptimal wrapper, far from pretty:
> (...)
(look, I said it wasn't pretty -- there are at least a dozen of problems
with this, but nothing a day of work I offered to do can't fix; I wrote
this because it was faster than talking without a concrete example to
have some
I believe I did my homework looking first -- are there other discussion
channels than this list that one should be aware of?
The lists are definitely the only place you *should* be aware of, but
there are a lot of informal spaces where discussions happen, because not
everyone is as
Agree on avoiding restarting old instances. If instances were atomic
services, s6-rc-update wouldn't restart them either.
OTOH, the template's files are copied, not symlinked, which means
restarting old instances will use the old template. Does this call for
an s6-instance-update program?
1 - 100 of 538 matches
Mail list logo
