Some glitches on skarnet.org

[Casper Ti. Vector]

* On , `Alternatively, you can
  checkout a copy of the skalibs "git repository' (yes, the double
  quote `"' is incorrect).

* On the cgit web interface, for example , the code section displays nothing
  except for line numbers.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some glitches on skarnet.org

[Casper Ti. Vector]

A shameless plug:  might be of
some help in understanding the protocol.  The script (169 SLOC as of
now) is not be directly usable to you since it is written in python, but
I tried quite hard to make the workflow as clear and concise as
possible :)

On Sat, Aug 13, 2016 at 01:05:30PM +0200, Laurent Bercot wrote:
>   So, I plan to understand exactly what an ACME client does before installing
> one - maybe a bash client (which would require installing bash on
> skarnet.org, which I've been able to avoid so far), or maybe I'll write a
> minimalistic C one. I'll probably get around to it somewhere in the course
> of 2017.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-linux-init, alpine linux, and initramfs

[Casper Ti. Vector]

On Tue, Jan 31, 2017 at 09:35:55PM +, Laurent Bercot wrote:
>   It won't do it in every case: parsing /proc/cmdline is hazardous and
> much more difficult than it appears. (There could be quotes, and quoted
> spaces, in the elements.) We had a discussion about this on the Alpine
> development IRC channel, and it appeared that you can't do it safely
> with less than 50 lines of shell.

Perhaps more than 50 lines if you insist on use sh(1) because of the
usage of `eval' to set up dynamically-named variables, eg.:
> eval "${opt%%=*}='${opt#*=}'"
which, for opt="a=b' dont-rm -rf /'", becomes
> a='b' dont-rm -rf /''

However, the code can be very simple if you use a shell that does not
forbid "$key=val", and restrict the kernel command line as a
space-separated list of strings in the `key[=val1,val2,...]' form,
where `key's are valid shell variable names, and `val's are strings of
non-whitespace non-comma printable characters.  Here's an example
written in rc(1) (the Byron Rakitzis implementation):
> for (opt in `{cat /proc/cmdline}) {
>   if (~ $opt *'='*) {
>   key=`{echo $opt | sed 's/=.*$//'}
>   KOPT_$key=`{echo $opt | sed 's/^[^=]*=//; s/,/ /g'}
>   } else if (~ $opt no*) {
>   KOPT_`{echo $opt | sed 's/^no//'}=no
>   } else KOPT_$opt=yes
> }

>   The simplest solution, if you control the kernel command line, is to
> duplicate the root= argument with something the kernel will let through:
>   The kernel keeps the "root" argument, but puts "rootfs" in the
> environment, which you can easily read from.

>From those distros I have used, it seems that the kernel does not eat
anything from its command line, so I think it is unnecessary to
duplicate the `rootfs' parameter.

>   Once it has all the information it needs and has found its rootfs, the
> initramfs script doesn't need environment variables anymore, so it
> cleans up its environment. You should do the same: be as transparent as
> possible, do not leak into /sbin/init anything it doesn't strictly need.
> /sbin/init may have the environment variables set by the kernel, but it
> definitely shouldn't have any variables set by your initramfs script.

In addition, the cause for `KOPT_*' not showing up in Alpine init is
that sh(1) does not leak manually set variables except when told to
`export'.  In contrast, rc(1) does not have the `export' builtin, and
simply exports all variables.  Anyway, you can use the following
chainloading command to clean up the environment just before switching
root:
> /bin/busybox env -i [key1=val1 key2=val2 ...] \
>   /bin/busybox switch_root $root $init

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-linux-init, alpine linux, and initramfs

[Casper Ti. Vector]

Oh, now I understand what you and Laurent meant: apart from
`/proc/cmdline', the kernel also exports its boot parameters (except for
`root=...', parameters without a value and possibly something else) into
the environment of the init process.  This is really useful when not all
parameters need to be scanned, which is often the case.

On Wed, Feb 01, 2017 at 10:11:12AM +0100, Guillaume Perréal wrote:
> For my tests, I used the following snippet as an init script:
> 
>  #!/bin/execlineb -p
>  foreground { /usr/bin/s6-printenv }
>  /bin/sh
> 
> Neither execlineb nor s6-printenv touch the environment. Yet, I had 
> "modules" and "initrd" variables (which are in the kernel command line) 
> but not the "root" one.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-rc:

[Casper Ti. Vector]

Using the fifo trick [1]?  As a side note, though the s6 documentation
considers it "dirty", similar methods [2] are widely used for process
synchronisation in CSP-style concurrency.

[1] .
[2] .

On Fri, Jan 27, 2017 at 11:04:10AM +0100, Guillaume Perréal wrote:
> I have added "s6-sleep 1" before s6-rc-init to fix it, but I am 
> wondering if there is an more elegant yet simple way to handle this ?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: execline and $0-based stuff

[Casper Ti. Vector]

An example of my attempt, already working on at least 2 Alpine machines:

> $ ls -d /etc/s6-rc/main/*getty*
> /etc/s6-rc/main/getty.tty1

> $ cat /etc/s6-rc/base/getty/run 
> #!/bin/rc -e
> exec >[2=1]
> . /etc/s6-rc/bin/fn.rc
> exec `{cdr $self} 38400 $name linux

> $ cat /etc/s6-rc/bin/fn.rc
> #!/bin/rc
> fn car { echo $1 | sed 's/^.*\.//' }
> fn cdr { echo $1 | sed 's/\.[^.]*$//' }
> # ... [code used in other templates] ...
> self=`{basename `{pwd}}
> if (~ $self *.log) {
> logd=/var/log/`{cdr $self}
> } else name=`{car $self}
> # ... [code used in other templates] ...

On Sat, Feb 18, 2017 at 01:46:20PM +0100, gperr...@free.fr wrote:
> extract a part of the path of the executed script ($0) in a variable

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Some glitches on skarnet.org

[Casper Ti. Vector]

Found this just now: : pure C, no
python or shell; developed by the OpenBSD people and already included in
OpenBSD, which at least makes the code not smell very insecure :)

Nevertheless, that client is not mininalistic, which might be a little
annoying for you...

On Sat, Aug 13, 2016 at 01:05:30PM +0200, Laurent Bercot wrote:
>   Yes, it's something that I plan to do at some point. But I don't want to
> just install software on skarnet.org, even a simple bash client, that's at the
> core of the security infrastructure, and not understand it; I want to be able
> to tell exactly what's going on with, or at the very least put a good amount
> of trust in, *everything* running on the server. That's why I'm not using
> Python, among a lot of other things.
>   So, I plan to understand exactly what an ACME client does before installing
> one - maybe a bash client (which would require installing bash on
> skarnet.org, which I've been able to avoid so far), or maybe I'll write a
> minimalistic C one. I'll probably get around to it somewhere in the course
> of 2017.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

The s6-rc-compile segfault and the s6-rc failure still occur with `s6-rc
0.2.1.1-r0' from the alpine testing repository.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

I just found myself being extremely careless this time: when I said "the
alpine testing repository", I really meant `edge/testing', but s6-rc
v0.2.1.1 should be in `edge/main', so probably I just installed s6-rc
v0.2.0.1 from `v3.6/main', and rediscovered the original problems with
the old alpine package.  The v0.2.1.1 package seems to work fine now.
I am very sorry for the disturbance :(

On Tue, Jul 04, 2017 at 11:59:01PM +, Laurent Bercot wrote:
>   I cannot reproduce the issue

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

[Casper Ti. Vector]

Which would require rc(1), but it is unfortunately "unmaintained" in
Alpine.  Following are static-compiled binaries for the 1.7.4 version:
x86_64: <https://drive.google.com/open?id=0B3FGvKEMCkmXMm9odWhVdVR1Znc>
x86: <https://drive.google.com/open?id=0B3FGvKEMCkmXLUJDQll2VFNsNVE>

Attached are their checksums (plus that for the `alpine-s6rc-conf'
tarball) signed with my OpenPGP key.

On Sat, May 20, 2017 at 12:20:30PM +0800, Casper Ti. Vector wrote:
> follow the README in the tarball

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

[Casper Ti. Vector]

:(

On Sat, May 20, 2017 at 12:51:13PM +0800, Casper Ti. Vector wrote:
> Attached are their checksums (plus that for the `alpine-s6rc-conf'
> tarball) signed with my OpenPGP key.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



SHA512SUMS.asc
Description: application/pgp-encrypted

Re: Using execline in place of shell for s6/s6-rc setup: environment variables?

[Casper Ti. Vector]

Something strange happened to my previous mail: the `SHA512SUMS.asc'
file only had one line saying `Version: 1'; perhaps a problem with mutt.
The correct version is now attached.

And I am very sorry for these spammy mails :(

On Sat, May 20, 2017 at 12:51:13PM +0800, Casper Ti. Vector wrote:
> Attached are their checksums (plus that for the `alpine-s6rc-conf'
> tarball) signed with my OpenPGP key.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

5b47a73c88ba9b98786ffd23a11e0c185019cac3ee740b5c5d29b81d2fe745de99530c8027421ff3af1b282906d829a89914a594247204da187ec761c92f892e
  alpine-s6rc-conf.tgz
f30f206f9ae8db4ec3356a86ba4e64192c7608db38a95a3ea2ae546c47fee6ae1af3aadd7612abfa28702ff9bae0b6a3f9a3277e3153a14dbe801273c50f2d7b
  rc-1.7.4-x86_64.gz
f0621fb419c244101d5841a976477ab333787f74d282f8fd339e423cf2610479c79fbe36f8387cfcea3c2a5384781aa0e656424981e8b3f67114fec9c6512c75
  rc-1.7.4-x86.gz
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE2RLoDKoyqvVE59qjgf3bVMjcwokFAlkfxggACgkQgf3bVMjc
wokcTA/+KybmGgrf3P9EFq2MiExRCdXtjeDZdmB7CjNa8HQgL8j4YRN24dlNhBVb
V5FXGV0fJwELwiltcW+jU65P8s4UzRclcaxZEdHZpgK++tod2c38r3iRUvE7vTu2
NKP2OimwVRozvJrxWX4a2vy2eIwzLrzbB8ALgKRAb4bz0tojpKt9pqD81RI43giY
VEhN/ZITiQkwq7gWvtqEnuK062CaDc+pIlakO70l2fg9T9arctUnpZpMwTmoufUN
oloTA8FgCNrJ2FNHhYVEMCYWLZ3N6Dy44AJ5QpKBxoO1ujAXEfmDBVwNCFPb1P1v
u39SdiSLCZi2GgyecM/MWfTmvF4WWVDhplRr6caubcWYvvyMyaE+NFg+PREoP/4l
X4Fqef92wuBntMAvOKgz78AKvAF168ERieVKv5xECNiUsfn05NWHJI8MzA1JMFiT
l4ZiAUSrn84kVturKi9vqHiOLzFZ4EhcjOu24kHU0j65SegK6cTeK10CoKgT8Ly5
J3guRnPj5n7HvAiQpcpC74nc+u7YaiYBwXok+y7eIIhDM4eXKOCBxSIjT//i7N14
NGRQtjRjwXf+CBRFsMNA/hIVJm3RqT4AfDbh4kCzjEMSL7v9I3xyc2n7FFjUzqhF
3mKmIbz3caTxoDu903PgjKPROObSSZLaZ4LyPdf7d0idmRQui7E=
=zdQc
-END PGP SIGNATURE-

Re: Some glitches on skarnet.org

[Casper Ti. Vector]

By "full upgrade", I actually meant "no downgrading" instead of
"disabling HTTP", so I take your answer as a "yes" :)

After some summarising, I found the list of skarnet.org self-links to be
fairly trivial:
* Links in skarnet.org packages: I note that `skarnet.org' links have
  just been fixed, but HTTP links to `git.skarnet.org' and (legacy?)
  `www.skarnet.org' are unchanged as of now; if you do not mind doing a
  little more cosmetics, there are also some textual references to
  `www.skarnet.org'.
* The local mail list archive: all links are using HTTP.
* The cgit interface provides Atom feeds using HTTP, eg.
   referencing
  .

Also, if you would like to adjust external links:
* Links in skarnet.org packages and all CGI pages.
* Extra static pages: `/downtime.html', `/ispchange-20040504.html',
  `/mirrors.html', `/powersupply-20070720.html', `/poweredby.html',
  `/cracks.html', `/index.html', `/lists.html', `/software/index.html',
  `/software/djbdns-fwdzone/index.html',
  `/software/nistp224-buffer/index.html',
  `/software/qmail-qmtproutes/index.html'; and I found the last three
  pages to be referenced as `.../index.html' instead of `.../' in
  `/software/index.html'.

(I probably look like an irredeemable clean freak now...)

On Tue, May 23, 2017 at 09:06:07AM +, Laurent Bercot wrote:
>   The answer is no (I still want to provide HTTP), but I agree that
> downgrading is bad, so I'll still take a list :) I'll switch to
> scheme-less URLs gradually, so that when you're using HTTPS, you
> stay with HTTPS.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Problems with recent versions of s6-rc

[Casper Ti. Vector]

* s6-rc-compile segfault: boot up a VirtualBox VM with (for
  reproducibility) `alpine-standard-3.6.0-x86_64.iso', log in as root
  (no password needed), install s6-rc (v0.2.0.1 as of now) from the
  Alpine v3.6 repository, uncompress the attached tarball, and run
  $ rm -rf compiled && s6-rc-compile compiled main
  The outcome can be a hanging `s6-rc-compile' process, a segfault or a
  normal exit, so you might need to try a few times.

* Incompatibility of the compiled database: s6-rc commit 543c1405 breaks
  the backwards compatibility of the compiled service database, which is
  unfortunately not mentioned in `upgrade.html' (or is it expected to
  recompile the database whenever s6-rc is updated?).

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



main.tgz
Description: GNU Unix tar archive

Re: difference between bundles and dependencies in s6-rc

[Casper Ti. Vector]

.

On Fri, May 26, 2017 at 03:58:15PM -0500, Brett Neumeier wrote:
> If there is a functional difference -- what is it?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

Additionally, on my machines, which now use freshly compiled databases,
when running `s6-rc -u change default' in `rc.init', with a small but
significant probability (one in a few) the procedure ends up with this
error:
> s6-svlisten1: fatal: unable to ftrigr_update: Broken pipe
> s6-rc: warning: unable to start start service s6rc-oneshot-runner: command 
> exited 111

On Thu, May 25, 2017 at 12:58:30PM +0800, Casper Ti. Vector wrote:
> * Incompatibility of the compiled database: s6-rc commit 543c1405 breaks
>   the backwards compatibility of the compiled service database, which is
>   unfortunately not mentioned in `upgrade.html' (or is it expected to
>   recompile the database whenever s6-rc is updated?).

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

On Thu, May 25, 2017 at 10:17:22AM +, Laurent Bercot wrote:
>   All the problems you report should be fixed with skalibs-2.5.1.1, which
> should already be available in Alpine. Are you still experiencing issues
> with skalibs-2.5.1.1 ?

I experienced this when updating Alpine from v3.5.2 to v3.6.0 on these
machines; the v3.6.0 release have already covered skalibs v2.5.1.1.

>   It is expected to recompile the database on major upgrades.
> 0.1.0.0 to 0.2.0.0 is a major upgrade (else the release would have been
> called 0.1.1.0). Sorry if that was not clear; I will make it
> explicit when it happens again.

I see; thanks then.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

On Fri, May 26, 2017 at 12:15:39AM +, Laurent Bercot wrote:
>   When it's about debug information such as strace outputs
 ;)

>   Except that when you send a file to a mailing-list
Well this is the problem I neglected: it is not Gentoo or not, but bug
trackers have their own persistent storages that are not duplicated by
mails.  I will post debug info to pastebins then.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

After reboot-looping a test VM for many times, this is also reproduced
successfully; attached is the log.

On Thu, May 25, 2017 at 09:07:26PM +0800, Casper Ti. Vector wrote:
> The issue with `s6-rc' seems to be difficult to reproduce when `s6-rc'
> is debugged by strace, so I am unable to produce a log for it now.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

Not even in a VirtualBox VM?  Seems more interesting than I thought...
Attached is the logs of `s6-rc-compile' for the three cases.  The issue
with `s6-rc' seems to be difficult to reproduce when `s6-rc' is debugged
by strace, so I am unable to produce a log for it now.

On Thu, May 25, 2017 at 11:43:45AM +, Laurent Bercot wrote:
>   Can you then please send me a strace of the failing programs? I can't
> reproduce.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



compile-log.tgz
Description: GNU Unix tar archive

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

A person on this list kindly told that no attachment appeared; but
actually I *did* attach a gzip'ed version of the log as `rc-err.log.gz',
so we are perhaps facing a problem with some steps in the mail delivery.
Attached is a tgz version; please do tell me if it disappears again.

On Thu, May 25, 2017 at 09:19:26PM +0800, Casper Ti. Vector wrote:
> attached is the log.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C



rc-log.tgz
Description: GNU Unix tar archive

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

Hello, is there any progress on this issue?

On Fri, May 26, 2017 at 04:00:06AM +, Laurent Bercot wrote:
>   Tomorrow I'll report that to the Alpine devs, and investigate what
> could have gone wrong. And I'll have to either pay more attention to
> Alpine quality control, or drop maintenance of the Alpine packages, because
> I lost half a night on this and I can't afford to waste time on f*cking
> distro bugs.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

Thanks.  Seems I need to pin the s6-related packages at alpine 3.5.x on
my servers for a longer time...

On Sun, Jun 04, 2017 at 11:21:30AM +, Laurent Bercot wrote:
>   We have confirmed that it is an Alpine problem. We're not sure
> exactly where the problem occurs (the usual suspect, grsec, has been
> innocented), but we know it's related to the Alpine package build
> and to virtualization.
>   In any case, the s6-rc code is good. You can confirm it by building
> it yourself.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Problems with recent versions of s6-rc

[Casper Ti. Vector]

Well I think pastebins really tend to be unreliable (most importantly,
content disappearing at unexpected time), so small files (whether text
or binary, as long as they are relevant) are best posted directly to the
mail list; and since compression saves space, tarballs and zipballs are
suitable for files longer than a few dozens of lines.  This practice is
recommended on some FOSS bug trackers, eg. .

On Thu, May 25, 2017 at 03:19:51PM +, Laurent Bercot wrote:
>   It is intentional that binary attachments are stripped when sent to the
> list. I don't want to spam every subscriber with binaries. When I say
> "please send a strace", I really mean "please paste a strace to some
> website such as pastebin, and send a link".
>   Please don't try and circumvent the attachment stripping, or I'll
> have to tighten it. :P

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: PEBKAC prevention with s6-rc

[Casper Ti. Vector]

I see; I think this version is OK, but the update seems to be absent
from the git repository?

On Sat, Sep 30, 2017 at 02:54:56PM +, Laurent Bercot wrote:
>  https://skarnet.org/software/s6-rc/upgrade.html ?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: PEBKAC prevention with s6-rc

[Casper Ti. Vector]

I think the update makes it clear enough to me, but I did not find any
update on the recompilation issue.

On Sat, Sep 30, 2017 at 01:24:46PM +, Laurent Bercot wrote:
>  Please tell me if it makes things clearer for you, or if something more
> is needed.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: PEBKAC prevention with s6-rc

[Casper Ti. Vector]

Thanks; I think these fixes would prevent most people from making the
same mistake I made :)

On Sat, Sep 30, 2017 at 07:37:26PM +, Laurent Bercot wrote:
>  Whoops! Sorry, fixed. :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: [announce] skarnet.org August 2017 release

[Casper Ti. Vector]

Does this mean something interesting with bugfixes in other packages? ;)

On Mon, Aug 28, 2017 at 11:25:58PM +, Laurent Bercot wrote:
>   - Bugfixes. (No security issue involved.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: SIGFPE in s6-rc-init 3.0.0 etc,...

[Casper Ti. Vector]

On Fri, Dec 15, 2017 at 12:08:56PM +, Laurent Bercot wrote:
>  The SIGFPE sounds very weird because s6-rc doesn't use floating point
> anywhere, but if it's hitting undefined behaviour then everything is
> possible.

>From the `FPE_INTDIV' part of , it
seems that the signal was triggered by an integer division by zero...

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

[Casper Ti. Vector]

Will there be a plan to add something roughly isomorphic to libudev?

On Mon, Oct 23, 2017 at 08:02:33AM +, Laurent Bercot wrote:
> mdevd is an uevent manager reading a sequence of uevents and handling
> them without forking, that understands the full /etc/mdev.conf format.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: .env file handling

[Casper Ti. Vector]

See also rc(1) :)

On Tue, Oct 24, 2017 at 10:55:28PM +0200, Guillaume Perréal wrote:
> The scoping might be a bit challenging, but the variable substitution system
> is royal. I do not constantly ask myself "what will happen if this variable
> contains a space, or a quote ?".

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-svscan - controlling terminal semantics and stdin use

[Casper Ti. Vector]

On Mon, Jan 01, 2018 at 07:53:39PM -0800, Earl Chew via skaware wrote:
> If instead, I start s6-svcscan at the terminate and terminate it with ^C
> (SIGINT), what I observe is that the child s6-supervise processes
> terminate abruptly and their child service processes are orphaned. I
> think the issue is that the child s6-supervise processes continue to be
> part of the same process group as s6-svscan, which in turn is attached
> to the controlling terminal of the session. The SIGINT is delivered to
> all the processes in that group, which terminates the s6-supervise
> processes immediately, thus causing their children to become orphaned.

Perhaps you can try the `-s' option of s6-svscan?

> I was thinking about how to go about making the two scenarios more
> alike. Using s6-setsid as part of the */run supervision scripts seems
> like a solution, but it will not have the right effect since what is
> required is not to create a process group for the */run process, but to
> dissociate the s6-supervise from process group of s6-svscan. This means
> that any potential remedy would have to be placed around the fork() in
> s6-svscan.

(Actually s6-supervise does setsid() by default before exec()ing into its
supervised process; there is an optional `setsid' control file to disable
this behaviour.)

> My second observation is that stdin of s6-svscan is inherited by all its
> s6-supervise children. I'm wondering if there is anything to be gained
> by that, and whether it would be less surprising to set stdin to
> /dev/null after fork() since having a herd of processes attempting to
> read from the same stdin does not seem to lead anywhere useful.

I think `s6-svscan /path/to/sevices < /dev/null' should be enough?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-svscan - controlling terminal semantics and stdin use

[Casper Ti. Vector]

On Tue, Jan 02, 2018 at 08:33:18AM -0800, Earl Chew via skaware wrote:
> I do not think that my suggestion of placing the children of s6-svscan in a
> separate process group from s6-svscan itself changes any of these
> objectives. Each service would continue to apply its own session leader role
> by default, and explicit requests to tear down the supervision tree and the
> supervised processes should do just that.

Perhaps this would achieve what you want:
# mv /path/to/s6-supervise /path/to/s6-supervise.bin
# > /path/to/s6-supervise printf \
  '#!/bin/sh\nexec /path/to/setsid /path/to/s6-supervise.bin $@\n'
(Similar tricks have been used to endow /path/to/s6-supervise with other
"capabilities" without really modify the source code; also note that the
shell would introduce additional variables into the environment, so you
can also consider using execline.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Question about enable-absolute-paths option

[Casper Ti. Vector]

On Sun, Sep 02, 2018 at 02:12:47PM +0800, Shengjing Zhu wrote:
> Thanks for this note, I haven't looked at these packages. At first I
> thought execline binaries will only be called inside execlinep
> scripts. Could you give some examples that s6 calls these binaries
> directly except exelinep?

My init/rc framework, slew [1], although base on s6/s6-rc, uses the
rc(1) shell as its main scripting language, and still often makes use of
the `emptyenv' command from execline.  Also, some complex `./run'
scripts like [2] can be readily rewritten in a shell [3], and these
translated versions will use more commands from execline.

[1] .
[2] 
.
[3] .

BTW, greetings from a compatriot :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Question about enable-absolute-paths option

[Casper Ti. Vector]

On Sun, Sep 02, 2018 at 11:17:20PM +0800, Shengjing Zhu wrote:
> The actual reason is that I can't afford time to argue with other
> developers. When I ask on debian-devel list, at least someone is
> object to this[1]. I'd to admit that I'm not good at argument. The
> simple solution I see is to put notes in the debian package.
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250

Actually, there can be a compromised plan: implement the chainloading
functionalities in Scheme, and the execlineb interpreter as well as the
commands like `if' and `background' would no longer be necessary [1].
This plan still requires the presence of commands like `cd' and `wait'
$PATH, but the number of commands which the Debian people consider
"confusing" is greatly reduced.  (Disclaimer: this is my own suggestion,
and will probably not be endorsed by Laurent.)

[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: execline

[Casper Ti. Vector]

Some relatively minor points to add:

On Tue, Apr 10, 2018 at 11:12:30AM +0800, Casper Ti. Vector wrote:
> * Perferably, support something like scsh

Though I like the idea of scsh, I still find it slightly large; I think
a set of suitable macros and library functions for Chibi might be a
better route.

> Considering the existence of elegant yet performant self-hosting Scheme
> compilers (like Chez, which self-compiles in seconds), the proposed
> solution can also be simpler in terms of total complexity.

By referring to Scheme compilers, I do not intend to exclude Scheme
interpreters from our candidates, but to show that the total complexity
of the proposed implementation can be comparable to (or even lower than)
that of the current implementation.

And by the way, since the chainloading procedure itself consumes very
little time after all, even if the Scheme implementation is relatively
slow, the overall performance of the system would be nearly unaffected.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: [announce] execline-2.4.0.0

[Casper Ti. Vector]

On Sat, Mar 31, 2018 at 11:15:43PM +, Laurent Bercot wrote:
>  So, with user-friendliness as a major goal, with version 2.4.0.0,
> some execline commands have changed names.

One step closer to scsh [1] for execline ;)
Any plan for backward compatibility or at least a transition phase?

[1] .

P.S. Output of date(1):
> Mon Apr  2 01:41:21 CST 2018

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: On lh-bootstrap and mkroot

[Casper Ti. Vector]

On Mon, Sep 03, 2018 at 02:34:41PM -0400, Zach van Rijn wrote:
> The ones in [3] are not stripped, and that accounts for most of
> the size discrepancy. I will ask Rob to consider adding that to
> his 'mcm-buildall.sh' script. I simply build/host binaries.

Thanks for explanation; now I understand.
I think this would at least save the site owner some bandwidth :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: On lh-bootstrap and mkroot

[Casper Ti. Vector]

On Mon, Sep 03, 2018 at 08:47:32PM +, Laurent Bercot wrote:
>  I have asked landley before whether he shared my interests for weird
> things such as using less resources than the shell, or supervision
> systems. His answer was a resounding and unambiguous "no". His interests
> are focused on making a GPL-free platform suitable for systems such
> as j2 and Android, and he cares more about porting the existing flawed
> tools that people know than about rewriting the world in a better way.
> Which is totally fair.
> 
>  Let him do what he wants to do, let me do what I want to do, and pick
> your favorite parts. This will work a lot better for everyone. :)

Many thanks for the clear explanation.  It should be quite obvious now
that my goal, when choosing the toolsets, is somewhere between the goals
of you two people.  (Another goal of mine, which is one of a much longer
term, is the reconciliation of Lisp and Unix [1]: "interfaces should be
questioned right down to the libc", and IMO also to the language itself;
ultimately, this would probably result in further minimisation in total
complexity of the system.)

[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

On lh-bootstrap and mkroot

[Casper Ti. Vector]

Although I have tried neither of lh-bootstrap or mkroot [1], I noticed
that the toolchains of the former is nearly one magnitude smaller than
those [2] of the latter, while both seem to be based on musl and
statically linked.

[1] .
[2] .

Out of curiosity, may I ask what is the cause of this huge difference?
Additionally, is there a possibility that the two projects join forces,
so one becomes an add-on to the other, and minimising wheel reinvention?

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: S6 integration in mainstream linux distributions

[Casper Ti. Vector]

On Fri, Mar 15, 2019 at 02:33:50PM +0100, Oliver Schad wrote:
> We found the project "slew"[1] which offers a nice way to manage oneshot
> services, cause execline doesn't offer the things we want to re-use
> today.

A history note: once a friend of mine, when introduced to execline, told
me about the Thompson shell [1].  The Wikipedia page said, "by the 1975
release of Version 6 Unix, it was becoming clear that the Thompson shell
was inadequate for most serious programming tasks", which might also
"explain" some people's feeling about execline.

[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: S6 integration in mainstream linux distributions

[Casper Ti. Vector]

On Fri, Mar 15, 2019 at 02:33:50PM +0100, Oliver Schad wrote:
> The next question was the long-term strategy with systemd: we have 2
> approaches
> 
> 1) mix systemd (PID 1) to use the boot phase (especially one shots)
> and later (after system initialization) use s6 to manage all services.
> 2) just use s6

Hello, I am the author of slew, and use it on quite a few real-life
systems, and it works quite nicely.  I think its mechanism for system
initialisation is quite flexible, and oneshots for requirements you
mentioned in the later mail, including encrypted filesystems, logical
volumes, iSCSI etc, can be easily plugged into the initialisation
procedure.

And as you might have already noticed, the services definitions (whether
longruns, oneshots or bundles) in slew are fairly easy to write: at
least for longruns, it is usually straightforward enough to manually
translate corresponding systemd units.

> My question to the list is, what do you use today? Do you use S6 in
> mainstream distributions and how?
> What are your problems you see? Should we work together to solve them?

Currently I think the main technical limitation of slew (or perhaps all
supervision-based init/rc systems as of now) is the lack of a networking
component that has an interface somehow like Gentoo's netifrc or
Debian's ifupdown but integrates with the supervision system.  Without
such a component, configuring the network might appear to be a somewhat
frightening task to the average user.  See the original slew (formerly
s6.rc) announcement [1] for more details;

[1] 
.

> Our problem is the exiting code base in community projects, i.e. puppet
> config management. So we think, we should offer a systemctl commmand,
> which integrates with s6. We started that project.

I think the way supervision-based frameworks work in ways different
enough from systemd, so the attempt to emulate `systemctl' would create
more problems than it solves.  From my limited understanding, puppet is
just a way to replicate sysadmin commands to multiple nodes, and it
seems easier to directly write command wrappers for s6/s6-rc.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: S6 integration in mainstream linux distributions

[Casper Ti. Vector]

On Sun, Mar 17, 2019 at 03:21:43PM +0100, Oliver Schad wrote:
> I completely understand the purpose of execline but for server systems,
> which allocates more than 1 GB RAM regulary and running on modern x86
> CPUs, saving such resources is not needed for us(!).

Which is also why I usually avoided execline in slew :)

> Another point for our decision (for us) is, that we don't have knowlege
> about other shells than sh/bash - cause we don't see big benefits for
> us, we would stay in a homogeneous toolset.

You can have a look at rc(1).  Much cleaner than Bourne shells, much
easier to learn, and roughly on the same level of expressiveness.  I
think its benefits greatly overweigh the costs for migrating to it.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

[Casper Ti. Vector]

On Mon, Jun 03, 2019 at 08:36:00AM +, fungal-net wrote:
> Void (both glibc and musl) have had the whole s6 suite and skarnet libs
> on its repositories for all (xx) architectures.  s6-rc doesn't work out
> of the box though (tried and tried, I don't know enough to get it
> working).  I can install an arch kernel and make a bootable image by
> installing Obarun's s6-rc into void (glibc) and then 66.  Obarun's 66 is
> also in Void repositories, current and identical, I believe.

I use slew (, developed by myself)
on both Void (both glibc and musl) and Alpine (quite a few machines),
and all run smoothly.  What is you specific issue with s6-rc?  (Perhaps
this is more suitable for the supervision mailing list.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

[Casper Ti. Vector]

On Sat, Jun 01, 2019 at 11:55:57PM -0300, Guillermo wrote:
> Sooo... thoughts? Does anyone else use a sufficiently recent version
> of GNU libc and experience the same?

On my machine using Void with glibc 2.29 since 20190305, I never
encountered this issue.  I can confirm the behaviour you described of
getgrent(3), but it seems that prot_readgroups() (the only place where
getgrent(3) is called in s6-envuidgid.c) always calls endgrent(3) only
after getgrent(3) returns NULL, whether on error or upon exhaustion of
the entries; the `if (n >= max) break;' line would not be triggered
under normal circumstances because `max' is set to `NGROUPS_MAX' by
main().  Therefore, at least on my system, endgrent(3) is always called
with `errno' set to zero.

BTW, gcc with `-Wsign-compare' compains about the operand(s) of `?' on
the last line of prot_readgroups(); I do not know how Laurent thinks
about this.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

[Casper Ti. Vector]

On Sun, Jun 02, 2019 at 12:02:04PM -0300, Guillermo wrote:
> Do you happen to build skarnet.org packages statically linked to musl
> on those Void machines, or do you let them link to the distribution's
> libc?

On both Alpine and Void, I use the stock packages for skaware from the
distros, and both use dynamically linked binaries.

> Yeah, what triggers s6-envuidgid's failure here is that endgrent() is
> setting errno to the weird EINVAL value, the program checks errno
> *after* the call, and thinks it was caused by a failing  getgrent()
> call. Would it be to much to ask you if you could also check if
> endgrent(3) flips errno from 0 to EINVAL?

Actually it is trivial :)  Just compiled your test code and the runtime
result is:
> name: root members: (errno = Invalid argument)
> name: kmem members: (errno = Invalid argument)
> [...]
> End of file or error (errno = Success)
> errno = Success
So on my system endgrent(3) does not change errno from 0 to EINVAL.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

[Casper Ti. Vector]

On Mon, Jun 10, 2019 at 11:10:13PM -0300, Guillermo wrote:
> /etc/nsswitch.conf is 'owned' by sys-libs/glibc, and Gentoo's default
> comes directly from the libc's source package:

So Gentoo follows the upstream more closely, and the upstream default
would now result in the problem.  I think this is definitely worth a
glibc bug report.

> This is interesting. It hints at the problem really being in the
> upstream package. And you said that you added the 'db' service, so I
> take it that it wasn't there by default. Is this Void's current
> default /etc/nsswitch.conf?

Yes, precisely.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-envuidgid: Weird errors with GNU libc's getgrent() and endgrent()

[Casper Ti. Vector]

On Sun, Jun 09, 2019 at 05:28:49PM -0300, Guillermo wrote:
> /etc/nsswitch.conf, which I don't recall having ever modified, says:
>   group: db files

Try using `qfile -o' to find the owner, and subsequently how it should
originally have been?  (I used Gentoo for several years before migrating
to Alpine/Void two or three years ago, which is why I still lurk on its
forums.)

> I have no idea what changed, why this used to work before my upgrade
> of the libc, or why it apparently never failed for anyone else not on
> Gentoo.

You are correct: the issue can be reproduced on my void/glibc system if
`db' is added (whether prepended or appended) to the `group:' line in
/etc/nsswitch.conf.  (The /etc/nsswitch.conf is the distro-default for
glibc/x86_64 systems, unchanged on my system.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

s6-log timestamp bug after resuming; Plan 9 $path and /package

[Casper Ti. Vector]

1. After resuming from suspension or hibernation, s6-log no longer shows
   the correct timestamp.  Can this be fixed?  Thanks.

2. Some days ago I stumbled upon [1], and found it possibly a much less
   intrusive alternative to a centralised registry for command
   names [2].  Any thought on this?

[1] .
[2] 
.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

[Casper Ti. Vector]

On Sun, Sep 01, 2019 at 08:41:33AM +, Laurent Bercot wrote:
> Short answer: no, the system needs to readjust the system clock when
> resuming from suspension/hibernation; it's a problem not only with
> s6-log, but with every program using the system clock, so the problem
> should be fixed where it occurs.

I roughly see.  Other programs, like date(1) and conky, do seem to
output the correct time after resuming, but I (at least recently, and
you will know why in roughly two to four weeks) really do not have time
to investigate how that is done.

>  This is just a path searching convention, and the proposal is to
> basically add . to PATH for binaries containing (but not starting
> with) a slash. I personally think that anything involving . in PATH
> is a bad idea, but independently from that, I don't see how it relates
> to solving name conflicts in a distribution. Can you elaborate on how
> you would use this?

If I understood it correctly, Goodwin seemed to mean that any invocation
not beginning with `/', `./' or `../' are searched from $PATH, and thus
we can simply use `execline/import' to run `/bin/execline/import'.  BTW,
Plan 9 also has an `import' command: .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

[Casper Ti. Vector]

On Sun, Sep 01, 2019 at 10:54:44PM -0300, Guillermo wrote:
> OK. Going back to Casper's problem, I remember from old posts that he
> is using Void, Void packages a libskarnet built with
> --enable-monotonic, and the man page says that CLOCK_MONOTONIC does
> not count time that the system is suspended, so could that be the
> reason of s6-log's incorrect timestamps after suspension or
> hibernation?

Many thanks for the hint, and it is exactly because of this!  I built an
all-static version of s6-log that does not use `CLOCK_MONOTONIC' with
the script in this post, and confirmed that the symptom does not happen
with the customised version:
.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6-log timestamp bug after resuming; Plan 9 $path and /package

[Casper Ti. Vector]

On Sun, Sep 01, 2019 at 10:18:42PM +, Laurent Bercot wrote:
> Yes, it does. But --enable-monotonic is a bad idea for long-lived
> processes that need timestamping. I need better clock interfaces
> in skalibs, the current ones don't allow a run-time selection
> between clocks. Hopefully I can write those interfaces for 2.9.0.0.

So the supposed changes at [1] will come true?
(As a user, I will surely be glad about the effects.)
[1] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

The "Unix Philosophy 2020" document

[Casper Ti. Vector]

On Sun, Sep 01, 2019 at 05:11:57PM +0800, Casper Ti. Vector wrote:
> I roughly see.  Other programs, like date(1) and conky, do seem to
> output the correct time after resuming, but I (at least recently, and
> you will know why in roughly two to four weeks) really do not have time
> to investigate how that is done.

I finally finished the task I had been working on for almost two months,
and the result is at <https://gitlab.com/CasperVector/up2020/releases>
(cf. the afterword and the first part in the document for its relevance
to the skarnet mailing lists).  The first part may serve as a nice
introduction to s6, but will perhaps be a little banal to people that
are already conversant; these people are advised to read the third part.

Although the contents of the document are quite related to our mailing
lists, I do not think Laurent (by the way, I am sorry he might really
disagree with me on many points in the third part) would like to see too
much off-topic discussion on these lists.  So please send comments to me
via private mail or GitLab/GitHub issues if they are unrelated to
supervision/skaware; I will be especially interested in comments about:

* Logical fallacies or incorrect evidences (particularly in the first
  part); platitudes or bloated contents.
* Citations that should be added or removed; obvious mismatch between
  the Chinese and English versions (if you happen to understand both).
* Spelling or grammatical mistakes; obscure or wordy passages; aesthetic
  issues with typesetting.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: The "Unix Philosophy 2020" document

[Casper Ti. Vector]

(I guess discussions about this document is probably destined to be
off-topic on the skaware list, so further public mail in this thread
will only be posted to the supervision list; sorry for the disturbance.)

On Fri, Sep 27, 2019 at 04:38:16PM +0800, Casper Ti. Vector wrote:
> Although the contents of the document are quite related to our mailing
> lists, I do not think Laurent (by the way, I am sorry he might really
> disagree with me on many points in the third part) would like to see too
> much off-topic discussion on these lists.  So please send comments to me
> via private mail or GitLab/GitHub issues if they are unrelated to
> supervision/skaware; I will be especially interested in comments about:

I received comments and suggestions from multiple people, and would like
to express my sincere gratitude to these people.  Most of the issues
involved either are quickly resolvable, or require more time to address
but do not affect the main ideas expressed.  However, there is one issue
that I definitely need to ask for your suggestions on to resolve, and
the issue is about systemd: multiple people told me that they felt
uncomfortable about the recurring (but each time on a different aspect,
obviously) examples about systemd.

Before asking specifically for what I need, please allow me to briefly
explain why the document is in its current shape.  As can be seen from
the Afterword and Footnote 44 (as of v0.1.1), this document originated
from my reaction to the systemd fiasco; and as can be inferred from
Section 11, I find it impossible to discuss UP2020 without major
involvement with systemd.  So I already intended to blame systemd when
the document only existed in my imagination, and this intention is not
unjustified; but once systemd is involved, any argument must be backed
with enough evidences, hence the current shape of the document.

However, people told me that the document is not quite accessible to
those who know really little about systemd: one example is they do not
even know much about how the modules are organised in systemd, so the
claim that the systemd architecture has how cohesion and high coupling
may seem unfounded; because of this, I request your recommendation for
an accessible and not-too-boastful introduction to systemd suitable for
citation in the document.  Additionally, although there do not yet seem
to be other major technical faults in the recurring systemd examples,
they might really appear unpleasant for some readers, so I also request
your advices on how to reduce the "rantiness" of the document (eg. how
certain parts can be rephrased, or certain inessential examples be
removed/replaced) without harming its technical correctness.

A point to note is that I tried to choose a small yet most touted subset
of systemd features, and then to analyse how these features can be done
using s6 and friends, which I find a most efficient way to understand
their nature.  From what I know, there have been few systematic analyses
of systemd from the viewpoint of the daemontools-ish design, so I
believe that these technical arguments, in combination with UP2020, can
be much more convincing than other arguments available in showing why
systemd is bad.  Consequently I think that, with an appropriate amount
of publicity for the document, much more people would be willing
to keep an eye on, migrate to, or even help develop daemontools-ish
systems, potentially creating a mini-avalanche effect or even resulting
in a turning point in the "init wars".  However, the influx of people
into our circle will also result in a lot of noise (especially the noise
from some ill-intentioned systemd proponents) and a lot of additional
technical workload, so I request Laurent for a decision on whether to
publicise the document; and provided he agrees, I request you to help
spread it to appropriate places.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Unexpected behavior when updating exclusive policy package

[Casper Ti. Vector]

On Tue, Oct 20, 2020 at 02:53:50PM +0200, Oliver Schad wrote:
> But because it could cause a production problem (think about a master
> SQL server in a high traffic situation wich kills all his caches during
> restart and maybe will be down for minutes), I think there should be a
> way to give s6-rc some advice manually, how to handle that situation.

I did this in two steps (of course, both after first checking that the
service runs correctly and that `s6-rc-update -n' outputs were right):
* Add the new service, without declaring any dependencies on it; compile
  the service database, and run `s6-rc-update'.
* `s6-rc -u change' the new service, then declare any dependency on the
  service; compile the database again, and run `s6-rc-update' again.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: UCSPI-TLS for s6-networking?

[Casper Ti. Vector]

On Mon, Nov 16, 2020 at 02:05:27PM +, Laurent Bercot wrote:
>  If I needed to write an SMTP server that supports STARTTLS, the way
> I would do it would be the following:

I have also been thinking about a minimal implementation of STARTTLS MX
(I think this may be the only hard-to-remove instance of STARTTLS, since
the discontinuation of STARTTLS mail submission and retrieval is easily
supported by mail clients, and customer notices can be used to announce
the migration).

In my design, smtpd is a clear-text UCSPI application, which upon the
STARTTLS message exec()s into itself wrapped by s6-tlsd.  States are
passed across exec() through enviroment variables and command line
arguments (the latter only for non-sensitive information).  The client
does what is symmetric to those outlined above.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: [skaware] non privileged user oneshots/services launched by root not requiring the user to login 1st (like systemd @user ones) support

[Casper Ti. Vector]

On Thu, Oct 28, 2021 at 06:17:52PM -0600, Javier wrote:
> I use s6 on artix gnu+linux, and I think I'm missing support for
> oneshots/services like the systemd @user ones.  Those are still
> launched automatically when the system (not the user) starts.

The following may help as well:
.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

[Casper Ti. Vector]

On Wed, Jun 28, 2023 at 09:40:48PM +, Laurent Bercot wrote:
>  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)

Yes, after changing `attrp' in tryposixspawnearlyreturn.c to `attr'.

>  - the child_spawn*() family of functions now works properly even on
> this machine?

Partially, after an additional WEXITED is OR-ed with the options for
waitid() in child_spawn_workaround.c.  When given an unexecutable path,
child_spawn() returns 0, but errno is unset.

>  Also, can you please tell me what version of glibc these distribution
> versions are running?

glibc-2.17-317.el7.x86_64, from CentOS 7.9.2009.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

[Casper Ti. Vector]

I have realised that a simpler unexecutable path can be, for example,
/etc (is it mandated in POSIX?); this can save the mkstemp() call
in the sysdep test.

(And frankly I personally do not really find it much worthwhile to
introduce this amount of complexity for the broken dependency of a
quite minor performance optimisation...)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

[Casper Ti. Vector]

On Thu, Jun 29, 2023 at 08:21:19AM +, Laurent Bercot wrote:
>  POSIX doesn't mandate any path other than /dev/null and /dev/console
> and I'd rather not try executing them, who knows what weird permissions
> they may have on obscure OSes.

Actually I mean a *directory* that is guaranteed to exist (and meanwhile
unexecutable): so /dev here.

>  I agree it's a lot of work for not much, but as you said, the
> behaviour is arguably conformant, and your experience proves that old
> glibcs are still around, so I'd rather make posix_spawn usable where
> it exists instead of placing the burden of --with-sysdep-posixspawn=no
> on users who have a bad version.

Well I was intending to suggest that we simpliy avoided posix_spawn*()
where it disagreed with posix_spawn(3p); that is to say simply replacing
all previous `#ifdef HASPOSIXSPAWN' conditions with `#if (defined
HASPOSIXSPAWN) && (!defined SKALIBS_HASPOSIXSPAWNEARLYRETURN)'.  After
all it seems to me child_spawn*() is not used that prevalently, so the
performance penalty is really minor; of course, feel free to correct me.

And I probably also need to bring the incorrectness of posix_spawn(3)
to the attention of its (Linux manpages) maintainers.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: posix_spawn (was: Bugs with execline/s6 documentation and skalibs functions using posix_spawn())

[Casper Ti. Vector]

On Thu, Jun 29, 2023 at 11:04:33AM +, Laurent Bercot wrote:
>  Indeed, /dev should work; but using it still makes me queasier than
> crafting a nonexistent path.

Actually deliberately supplying a directory to posix_spawn*() is
a slightly deeper test, as the path exists but is unexecutable.
But surely this does not constitute a decisive advantage.

>  Of course, it doesn't matter for glibc, and it doesn't matter for
> s6 which needs fork anyway. And chances are that platforms that
> implement posix_spawn() with internals that are *not* fork+exec will
> not make it return before the spawning has really succeeded. But still,
> it's nice to make sure it can be used wherever it exists.

Now I see, thanks...

>  If you don't like the workaround, nobody's preventing you from using
> --with-sysdep-posixspawn=no manually. ;)

Yes, and I am keeping my origin solution at work intact :)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

[Casper Ti. Vector]

* In `trap.html', there is a reference to the removed `timeout' keyword.

* In `s6-svscan-not-1.html', the systemd unit (traumatic experience with
  it, as you may easily expect) lacks a `KillMode = process'.

* The child_spawn*() family of functions, depending on using posix_spawn
  or not, exhibit different behaviours on CentOS 7 (trauma again), as
  posix_spawnp() may return 0 with argv pointing to unexecutable paths.
  This, for example, results in s6-svscan not exiting on SIGTERM when
  .s6-svscan/SIGTERM is absent.  The behaviour of posix_spawnp() on
  CentOS 7 does not conform to posix_spawn(3p), but is documented in
  posix_spawn(3): "Even when these functions return a success status,
  the child process may still fail for a plethora of reasons related to
  its pre-exec() initialization.  In addition, the exec(3) may fail."

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

[Casper Ti. Vector]

On Tue, Jun 27, 2023 at 10:16:10AM +0800, Casper Ti. Vector wrote:
> * The child_spawn*() family of functions, [...]

Well, just found another one when handling the above issue:
* `flags.html' from skalibs references `--enable-sysdep-devurandom',
  which should now be `--with-sysdep-devurandom'.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

[Casper Ti. Vector]

On Tue, Jun 27, 2023 at 09:27:17PM +, Laurent Bercot wrote:
>  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.

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 expected.  Attached is a simple test.

>From the posix_spawn(3), which had the similar statement across the
three different versions above, there is also a statement two paragraphs
later: "The posix_spawn() and posix_spawnp() functions fail only in the
case where the underlying fork(2), vfork(2) or clone(2) call fails".
So if the manpage is followed to the word, the CentOS 7 behaviour is
expected; if posix_spawn(3p) is followed instead, any exec() error must
also be caught and result in returning 0, which we really expect.

If we assume posix_spawn(3) and posix_spawn(3p) were the only possible
behaviours (which is frankly not that reliable, judging from how
neither manpage noted the violation of conformance), then the two
behaviours could be distinguished with the attached test.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

/* ISC license. */

#include 
#include 
#include 
#include 
#include 

pid_t child_spawn0 (char const *prog, char const *const *argv, char const *const *envp)
{
  pid_t pid ;
  posix_spawnattr_t attr ;
  int e ;
  e = posix_spawnattr_init() ;
  if (e) goto err ;
  e = posix_spawnp(, prog, 0, , (char *const *)argv, (char *const *)envp) ;
  posix_spawnattr_destroy() ;
  if (e) goto err ;
  return pid ;

 err:
  errno = e ;
  return 0 ;
}

int main (int argc, char const *const *argv, char const *const *envp)
{
  if (argc < 2) return 1 ;
  printf ("%d\n", child_spawn0(argv[1], [1], envp)) ;
  return 0 ;
}

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

[Casper Ti. Vector]

On Wed, Jun 28, 2023 at 01:33:57AM +, Laurent Bercot wrote:
>  They're not the only possible behaviours: for instance, [1] shows that
> under some buggy qemu, posix_spawn() always returns early.

That seems to at least inadvertently comply with posix_spawn(3)...

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Bugs with execline/s6 documentation and skalibs functions using posix_spawn()

[Casper Ti. Vector]

On Tue, Jun 27, 2023 at 08:50:35AM +, Laurent Bercot wrote:
>  I believe the correct setting is actually KillMode=mixed; and the
> ExecStop= line is incorrect as well since ExecStop expects a synchronous
> command, not an asynchronous one. Better let systemd just send a SIGTERM
> to s6-svscan, wait for the supervision tree to exit on its own, and
> SIGKILL the stragglers. I pushed a fix accordingly.

Yes, I did my change in a haste and did not notice the `mixed' option
which is indeed better.  As you see, systemd waits for the stragglers
so that is at least correct, although the timeout (150s by default on
CentOS 7) is really exorbitant.

>  Yeah, well, tough for non-conforming systems.
>  That said, I also pushed a change last week that should have fixed
> this issue as a side effect, so it's all good. If you feel like it,
> you can try the s6-svscan version in the latest s6 git. :)

s6-svscan is quite a minor issue; I added .s6-svscan/SIGTERM for all
those scandirs which may unfortunately need to run on CentOS 7, as an
extra line of defence -- in addition to `--with-sysdep-posixspawn=no'
to skalibs.  The latter also fixes other programs that involve
child_spawn*(), including home-made ones (iotrap, discussed a few days
ago on the supervision list) and upstream ones (for instance trap).

I personally think `--with-sysdep-posixspawn=no' is the really correct
fix on CentOS 7, which fixes silent failures with eg.:
  #!/bin/execlineb -P
  trap {
SIGHUP { echo test }
  } /dev/xyzzy
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.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Update: rpm package for utmps, skalibs.

[Casper Ti. Vector]

On Mon, Apr 01, 2024 at 07:26:22PM +0800, qi wang wrote:
> Could you provide some suggestion? Or does anyone has some experience
> on that?

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).
And of course you should not list /usr/bin itself in execline's %files.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Update: rpm package for utmps, skalibs.

[Casper Ti. Vector]

On Mon, Apr 01, 2024 at 12:46:27PM +, Laurent Bercot wrote:
>  This means that your execline package cannot run execline scripts that
> use cd, umask or wait. It may work for you, but it is not suitable as a
> general audience package.

Certainly.  I avoid RedHat-like systems except when necessary at work.
(And so far /bin/sh happens to cover my chainloading needs at work well,
so the absence of the three utilities does not hurt me -- well not yet.)

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: Update: rpm package for utmps, skalibs.

[Casper Ti. Vector]

On Mon, Apr 01, 2024 at 09:09:52AM +, Laurent Bercot wrote:
> I haven't looked in detail, but I'm not sure why you want everything
> in one single RPM.

The packages he makes are not monolithic; the package by me, noted in
earlier messages, is monolithic, due to historical reasons and a lack
of time to migrate.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: is there any rpm package for utmps, skalibs?

[Casper Ti. Vector]

On Wed, Mar 27, 2024 at 07:43:24PM +0900, Dominique Martinet wrote:
> You should never need sudo in the install section of a spec file --
> you install to %{buildroot}, not directly to the system's bin/lib
> directories!

It is moving files *into* %{buildroot}, not *out of*. The converse
is done in the `build' section.  EPICS is a packaging-unfriendly
software framework, which resulted in forementioned ugly tricks being
involved.  I just reused the ugly tricks to make a monolithic package
that contains skalibs, execline and s6.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: is there any rpm package for utmps, skalibs?

[Casper Ti. Vector]

On Wed, Mar 27, 2024 at 01:41:49PM +0800, ericwq057 wrote:
> I search fedora39/centos 7, there is no available rpm package for
> utmps or skalibs. Asked google, there is only a very old (1.6) skalibs
> rpm spec available: https://github.com/imeyer/skalibs-rpm. Is there
> any plan to support rpm package? Recently I prepared to build rpm
> package for my project. Maybe I can help to build rpm package for
> skalibs and utmps. But I definitely need your help for rpm package.

Attached is spec code that builds a monolithic RPM package for skalibs,
execline and s6, tested under CentOS 7 and Rocky Linux 8; it needs to be
used with .  It uses ugly
tricks, most importantly invoking sudo to move files from/to root-owned
directories, and is therefore mostly intended for reference purpose
(apart from where it is actually used -- part of some EPICS-related
work which I plan to publish later this year).

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

%define skaver 2.13.1.1
%define execver 2.9.3.0

Name:   s6
Version:2.11.3.2
Release:2.el%{rhel}
Summary:skarnet's small and secure supervision software suite

License:ISC
URL:https://skarnet.org/software/s6/
Source0:https://skarnet.org/software/skalibs/skalibs-%{skaver}.tar.gz
Source1:https://skarnet.org/software/execline/execline-%{execver}.tar.gz
Source2:https://skarnet.org/software/s6/s6-%{version}.tar.gz
Patch0: %{name}-files.patch

BuildRequires:  gcc, make

%description

%prep
%setup -T -c -n %{name}
. %{_specdir}/fn-build.sh
tar xpf %{S:0}; _mv_commit skalibs %{skaver}
tar xpf %{S:1}; _mv_commit execline %{execver}
tar xpf %{S:2}; _mv_commit s6 %{version}
patch -p1 < %{P:0}

%build
stat -c '%a' /bin > bin.mod; stat -c '%a' %{_libdir} > libdir.mod
sudo chmod 0755 %{_bindir} %{_libdir}
%_chown_me %{_bindir} %{_libexecdir} %{_libdir} %{_includedir}
confargs='--bindir=%{_bindir} --libexecdir=%{_libexecdir} --disable-shared'
confargs="$confargs --with-sysdep-devurandom=yes --with-sysdep-posixspawn=no"
for pkg in skalibs execline s6; do cd "$pkg"
sed -i 's@/usr/lib\>@%{_libdir}@' configure
./configure $confargs; make %{?_smp_mflags}
mkdir image; make install; make DESTDIR="$PWD"/image install
cd -; done

%install
. %{_specdir}/fn-build.sh; mkdir rm
_mv_me "$PWD"/rm %{_bindir} %{_libexecdir} %{_libdir} %{_includedir}
sudo chmod "$(cat bin.mod)" %{_bindir}
sudo chmod "$(cat libdir.mod)" %{_libdir}
for pkg in skalibs execline s6; do
cp -a "$pkg"/image/* %{buildroot}
done
cd %{buildroot}%{_bindir}; rm cd umask; mv wait execline-wait; cd -
mkdir -p %{buildroot}%{_prefix}/lib/systemd/system \
%{buildroot}/var/service/.s6-svscan
install -m 0644 *.service %{buildroot}%{_prefix}/lib/systemd/system
install -m 0755 crash SIGTERM %{buildroot}/var/service/.s6-svscan
%_file_list %{_bindir} %{_libexecdir} > files.lst

%files -f %{_builddir}/%{name}/files.lst
%{_includedir}/skalibs
%{_includedir}/execline
%{_includedir}/s6
%{_libdir}/skalibs
%{_libdir}/execline
%{_libdir}/s6
%{_prefix}/lib/systemd/system/*.service
/var/service/.s6-svscan/*

diff -Nur 0/crash 1/crash
--- 0/crash	1970-01-01 08:00:00.0 +0800
+++ 1/crash	2023-12-20 23:21:29.956693399 +0800
@@ -0,0 +1,2 @@
+#!/bin/sh -
+
diff -Nur 0/s6.service 1/s6.service
--- 0/s6.service	1970-01-01 08:00:00.0 +0800
+++ 1/s6.service	2023-12-20 23:22:47.352897253 +0800
@@ -0,0 +1,14 @@
+[Unit]
+Description=s6
+Wants=rc-local.service
+After=rc-local.service
+
+[Service]
+ExecStart=/bin/execline-cd /var/service emptyenv -p s6-svscan
+ExecReload=/usr/bin/s6-svscanctl -h /var/service
+KillMode=mixed
+Restart=always
+
+[Install]
+WantedBy=multi-user.target
+
diff -Nur 0/SIGTERM 1/SIGTERM
--- 0/SIGTERM	1970-01-01 08:00:00.0 +0800
+++ 1/SIGTERM	2023-12-20 23:21:29.956693399 +0800
@@ -0,0 +1,3 @@
+#!/bin/sh -
+exec s6-svscanctl -t .
+

Re: is there any rpm package for utmps, skalibs?

[Casper Ti. Vector]

On Thu, Mar 28, 2024 at 03:58:24AM +0900, Dominique Martinet wrote:
> Also, if I'm reading this correctly it actually make /usr/bin 777
> because of flawed logic (stat -c %a /bin instead of %{_bin} (= /usr/bin);
> given /bin is normally a symlink to /usr/bin that stat will return 777
> and the later chmod to "restore" the mode will corrupt it)

Thanks; that's an overlooked (but fairly serious) bug, and has just been
fixed in the repository where the code come from.

> But hopefully it's only ever been run in throw-away containers

Which is the explicitly [1][2] only way it is expected to be used.

[1] .
[2] .

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C