Re: s6-linux-init without virtual consoles

[Brett Neumeier]

On Wed, Jun 7, 2023, 8:37 AM Oliver Schad 
wrote:

> Thanks for everything! s6 is one of the most beautiful software
> projects I know.


This right here --

S6, and honestly, the whole skarnet ecosystem of software, is a genuine
pleasure to work with. I agree with everything Oli said.

Cheers,

Brett

Re: Succinct, idiomatic abort in execlineb scripts?

[Brett Neumeier]

Perhaps just wrap each preparation command in an if block?

if { execline-cd data }

Will continue the script if execline-cd succeeds, and abort if it does not.

On Mon, Sep 5, 2022, 1:54 PM Saj Goonatilleke via skaware <
skaware@list.skarnet.org> wrote:

> Hello,
>
> Within the context of, say, an s6 run script that needs to do a little bit
> of
> prep work before execing into a server, it is often helpful to abort early
> if
> any of said prep work stumbles upon an unexpected problem.
>
> Maybe the filesystem is R/O.  Or full.
> Maybe an operator has fat-fingered something we need.
> Who knows!  Production is full of surprises.
>
> sh provides set -e, which is often satisfactory for simple prep scripts
> (if one is aware of its footguns).
>
> Is there a succinct, idiomatic set -e equivalent in the execline suite?
>
> I have included an example s6 run script below, which demonstrates the
> closest I
> have come so far.  fgsigwait is my alternative take on foreground[1].
> fgsigwait
> behaviour differs in the following respects:
>
> * fgsigwait exits[2] if prog1 exits with non-zero status.
>   foreground, by comparison, sets the ? environment variable and continues.
>   (fgsigwait -! reverts to foreground-ish behaviour.)
>
> * fgsigwait forwards some trappable signals to its child.  HUP, INT, etc.
>   This is where its name comes from.
>   (PID 1 is broken on some of our systems, which provided the initial
> motivation
>   for this hack.  fgsigwait always waits on prog1 after forwarding a
> signal.
>   This, plus execline's execution model, gave me fine control over when
> stuff
>   is forked -- and helped us avoid some Z process leaks.  Anyhoo.)
>
> fgsigwait otherwise aims to be a syntactic execlineb drop-in for
> foreground in
> cases where these features are desired.  Chaining stuff with fgsigwait
> emulates
> sh set -e without needing to repeatedly and explicitly test the ? env var.
>
> --- 8< ---
> #!/usr/bin/env -S execlineb -WP
>
> fdmove -c 2 1
>
> # slow-deathroll is a simple wrapper around
> # github.com/leahneukirchen/snooze
> # extends the s6 one-second restart penalty if we crash too soon
> fgsigwait { slow-deathroll }
>
> # Here is a simple example of some prep work.
> # We want to bail here if any of these things exit non-zero.
> fgsigwait {
>   execline-cd data
>   if -t { test ! -e live } fgsigwait { mkdir -p empty } ln -s empty live
> }
>
> # maybe a smidge more prep here...
>
> # all prep done.  exec into our server.
> nsd -d -c nsd.conf
> --- >8 ---
>
> This does work OK, but, every time I reach for my little program, I can't
> shake
> the feeling that I am probably reinventing some wheel.
>
> fgsigwait was implemented in Go, as is personal tradition when something
> need be
> hacked up in a hurry on the clock.  Spooling up the Go runtime eats a few
> extra
> milliseconds of time, and a few megabytes of memory.  While not practically
> significant to us -- we don't deploy to tiny machines -- a small part of
> me was
> sad to add bloat.  It would be nice if I could get rid of it.
>
> Is there a better way to abort?
>
> I suppose I could just fork sh, but inlining is pleasant when the prep is
> short.
>
> Thanks!
>
>
> [1]: https://skarnet.org/software/execline/foreground.html
> [2]: https://skarnet.org/software/execline/exitcodes.html
>

Re: s6-svscan can't find shared libraries

[Brett Neumeier]

On Wed, Dec 4, 2019, 10:49 J. Lewis Muir  wrote:

> I thought of another scenario: you don't have root on a machine, and
> you want to install software in your home directory.  Obviously,
> /etc/ld.so.conf won't work for this case.
>

Yes, and this kind of situation is exactly why there are facilities like
LD_LIBRARY_PATH and RPATH and RUNPATH and LD_PRELOAD available -- because
there are lots and lots of different scenarios you might encounter, and
having flexible options ensures that there is at least *something* you can
do that isn't awful.

For software in my home directory, I generally set PATH and LD_LIBRARY_PATH
-- setting both those variables seems nicely symmetrical.

I occasionally set RPATH or RUNPATH as well, in other situations. As long
as you're making informed decisions, and you are making the decisions for
yourself rather than trying to impose policy on other people, there are no
bad options.

>

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

[Brett Neumeier]

On Mon, Jun 10, 2019 at 9:10 PM Guillermo  wrote:

> El lun., 10 jun. 2019 a las 4:13, Casper Ti. Vector escribió:
> > > /etc/nsswitch.conf, which I don't recall having ever modified, says:
> > >   group: db files
> /etc/nsswitch.conf is 'owned' by sys-libs/glibc, and Gentoo's default
> comes directly from the libc's source package:
>

For what it's worth, on my system -- which was built using glibc 2.29 with
branch updates through 2019-05-03 and otherwise unmodified -- the
/etc/nsswitch.conf file does not contain any "db" references at all. Full
text is:

passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files

Presumably, it was installed this way because at the time glibc was
compiled there was a minimal set of packages available. I haven't looked at
the source carefully enough to determine whether that's actually the case,
but it seems a reasonable conjecture.

Anyway, I bet that's why I don't see the same error.

-- 
Brett Neumeier (bneume...@gmail.com)

Re: sdnotify-wrapper docs clarification

[Brett Neumeier]

On Fri, Feb 1, 2019 at 8:30 AM Profpatsch  wrote:

> > -f: do not doublefork. Use if the daemon waits for children it does
> > not know it has (for instance, superservers do this). When in doubt,
> > do not use that option, or you may have a zombie hanging around.
> Is the “that” here referring to the `-f` option or the daemon?
> In the first case, “do not use >this< option” is less ambiguous.
>
Hello Profpatsch!

Double-forking is a common idiom for daemon processes, as described for
example here:

https://stackoverflow.com/questions/881388

The main purpose of double-forking is to ensure that the long-running
daemon process is re-parented onto whatever `init` process is running as
PID 1. The process running as PID 1 has the responsibility of calling wait
on all of its child processes, even the ones that it did not fork directly,
so that their slot in the process table can be cleaned up; many programs
only call wait on the child processes that they know about.

So what this text is saying is, if you happen to know that the process that
is launching the daemon *does* call wait for child processes it does not
know about, then you can skip the double-fork operation. But if you are not
sure that it does that, you should omit the `-f` option and retain the
default double-fork behavior.

I agree that "...this option" is less ambiguous than "...that option".

-- 
Brett Neumeier (bneume...@gmail.com)

Re: execline "importas" documentation question

[Brett Neumeier]

On Sun, Sep 16, 2018 at 5:49 PM Colin Booth  wrote:

> I think I know what is going on. I assume you're running this on the
> commandline? If so, the shell is splitting prefix${FOO}postfix into
> three words ("prefix", "$FOO", "postfix"), then importas is deleting the
> middle one. If you write this as a full execline script like so:
> $ execlineb -c 'importas FOO FOO echo prefix${FOO}postfix'
> you'll see the full word deletion in action.
>

Ha, it was definitely a brain cloud, but it wasn't that. bash was, of
course, replacing ${FOO} with an empty string before running the importas
command.

The expected behavior does indeed show up if you single-quote that word so
that bash leaves it alone:

$ importas FOO FOO echo 'prefix${FOO}postfix'

$


-- 
Brett Neumeier (bneume...@gmail.com)

execline "importas" documentation question

[Brett Neumeier]

Hi,

The documentation for importas says:

"When *envvar* is undefined, and the -D option is not given, any variable
substitution <http://skarnet.org/software/execline/el_substitute.html> with
*variable* as the key will return no word; that is true even when the ${
*variable*} form to be substituted happens in the middle of a word (with a
prefix and/or a postfix), which means the whole world will be deleted. If
this is not the behaviour you want, use the -D option."

I'm trying to figure out what that means. When I ensure that FOO is not set
and run:

importas FOO FOO echo prefix${FOO}postfix

I get the output "prefixpostfix", which is identical to what I get if I add
a -D option with an empty word. If the whole word were deleted, I'd expect
to get empty output. (If the whole *world* were deleted, I'd expect to be
floating in space...)

-- 
Brett Neumeier (bneume...@gmail.com)

Tiny documentation patch for s6-rc

[Brett Neumeier]

max-death-tally and down-signal are now supported by s6-rc longruns, but
the documentation for s6-rc-compile doesn't say so. The attached corrects
that!

By the way -- I have s6/s6-rc/s6-linux-init set up as the init system for
my own GNU/Linux systems now, and it is _delightful_ seeing how nicely
everything fits together. Huge thanks for making this possible.

-- 
Brett Neumeier (bneume...@gmail.com)
From ab234d25ddf2fde606a0b8b7937462b4e2247f8f Mon Sep 17 00:00:00 2001
From: Brett Neumeier 
Date: Mon, 20 Aug 2018 11:31:02 -0500
Subject: [PATCH] s6-rc documentation fix

---
 doc/s6-rc-compile.html | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/s6-rc-compile.html b/doc/s6-rc-compile.html
index 000ea3b..57a6b95 100644
--- a/doc/s6-rc-compile.html
+++ b/doc/s6-rc-compile.html
@@ -275,8 +275,9 @@ about pipelines. 
 
   A mandatory regular file named run, as well as optional files
 named finish, notification-fd, timeout-kill,
-timeout-finish and nosetsid. These
-files will be copied, or recreated, in the generated
+timeout-finish, nosetsid, max-death-tally,
+and down-signal. These files will be copied, or recreated, in
+the generated
 service directory:
 they are meant to be used by the
 s6-supervise
-- 
2.18.0

Re: Naming of execlineb

[Brett Neumeier]

On Jul 27, 2018 12:52 PM, "Profpatsch"  wrote:

Why is the main binary named `execlineb` and not `execline`?
What does the `b`-suffix stand for?


I believe the original execline didn't support blocks; then the block
syntax was added as execlineb; and then it turned out that block support is
so useful that having the old version of execline around was pointless.

(On my systems, I link execlineb to execline.)

Re: Where does /dev get mounted?

[Brett Neumeier]

On Oct 30, 2017 1:50 PM, "Laurent Bercot"  wrote:

But I do have a question: as documented, I find that when stage1's child
> process execs into stage2, there is a devtmpfs mounted at /dev. I don't
> understand where this happens! I see where the stage 1 script mounts a
> tmpfs at /run, but I don't see anything there, or in the initial s6
> scandir, that mounts /dev. What am I missing?
>

 If you created your stage 1 script with s6-linux-init-maker, and you
see nothing in your stage 1 that mounts /dev, it means that you told
s6-linux-init-maker that your kernel automounts /dev at boot time.

 So, your /dev is already mounted when the kernel spawns init. The
kernel option triggering that behaviour is named CONFIG_DEVTMPFS_MOUNT.


Thanks Laurent! I'm sure that's how it's set up, and I just forgot I'd
enabled that configuration setting.

Cheers,

Brett

Re: Where does /dev get mounted?

[Brett Neumeier]

Hi Colin,

Thanks for your reply! This isn't a distribution, though, and has no
initramfs -- it's a system I built myself, kind of like a Linux From
Scratch.

On Oct 30, 2017 1:49 PM, "Colin Booth" <co...@heliocat.net> wrote:

> On Mon, Oct 30, 2017 at 12:14:50PM -0500, Brett Neumeier wrote:
> > Hi all,
> >
> > I have a system working well with the combination of
> s6/s6-rc/s6-linux-init
> > -- all of which work for me exactly as documented. So I don't have any
> > problems, really!
> >
> > But I do have a question: as documented, I find that when stage1's child
> > process execs into stage2, there is a devtmpfs mounted at /dev. I don't
> > understand where this happens! I see where the stage 1 script mounts a
> > tmpfs at /run, but I don't see anything there, or in the initial s6
> > scandir, that mounts /dev. What am I missing?
> Assuming a distro, the initramfs handles that. It also handles mounting
> /sys and running an initial udev coldplug cycle.
> >
> > Cheers!
> >
> > Brett
> >
> > --
> > Brett Neumeier (bneume...@gmail.com)
>
> --
> Colin Booth
>

Where does /dev get mounted?

[Brett Neumeier]

Hi all,

I have a system working well with the combination of s6/s6-rc/s6-linux-init
-- all of which work for me exactly as documented. So I don't have any
problems, really!

But I do have a question: as documented, I find that when stage1's child
process execs into stage2, there is a devtmpfs mounted at /dev. I don't
understand where this happens! I see where the stage 1 script mounts a
tmpfs at /run, but I don't see anything there, or in the initial s6
scandir, that mounts /dev. What am I missing?

Cheers!

Brett

-- 
Brett Neumeier (bneume...@gmail.com)

Documentation glitch for s6-uevent-listener

[Brett Neumeier]

s6-linux-utils/doc/s6-uevent-listener.html contains a broken link "mdevd".

Perhaps this should go to the busybox home page, or perhaps the mdev primer
at https://git.busybox.net/busybox/tree/docs/mdev.txt ?

-- 
Brett Neumeier (bneume...@gmail.com)

Re: difference between bundles and dependencies in s6-rc

[Brett Neumeier]

On Fri, May 26, 2017 at 8:17 PM, Casper Ti. Vector <caspervec...@gmail.com>
wrote:

> <https://skarnet.org/cgi-bin/archive.cgi?2:msp:1345:gcohklphppihpflkobnh>.
>

​Thanks for the link -- that also answers my question.

-- 
Brett Neumeier (bneume...@gmail.com)

difference between bundles and dependencies in s6-rc

[Brett Neumeier]

Hello Skaware!

I'm in the process of setting up s6 and s6-rc as the init and service
management systems for my linux system, and am curious: is there a
significant functional difference between a bundle service, and a oneshot
atomic service that does nothing but declares a bunch of other services as
dependencies?

If there is a functional difference -- what is it?

Cheers,

Brett

-- 
Brett Neumeier (bneume...@gmail.com)

Re: emptyenv and default path

[Brett Neumeier]

On Sat, Feb 6, 2016 at 1:31 PM, Colin Booth <cathe...@gmail.com> wrote:

> Due to the mechanism of exec, emptyenv doesn't modify it's
> environment, it modifies the environment that the next command
> receives. Because of this, emptyenv has a $PATH that it attempts to
> find foreground on. Foreground however does not receive a path and so
> falls back to using the default.
>

Got it. That was the conjecture I had come up with, I am very pleased to
have it confirmed. Thank you!

Regards,

Brett

-- 
Brett Neumeier (bneume...@gmail.com)

emptyenv and default path

[Brett Neumeier]

Hi,

I'm trying to get a handle on execline and have found some behavior that
perplexes me. I'm hoping someone can clarify what's going on!

I've installed all the skarnet stuff to /opt/skar. I configured skalibs
with "--with-default-path=/opt/skar/bin:/usr/bin:/bin"; my understanding is
that the various skarnet programs will use that default path if there is no
PATH environment variable.

When I don't have /opt/skar/bin in the PATH and I run this script:

#!/opt/skar/bin/execlineb -P
emptyenv
foreground { echo plugh } #1
foreground { echo plover }
env

of course execlineb crashes with "fatal: unable to exec emptyenv: No such
file or directory", because it can't find the emptyenv program.

When I change that line to /opt/skar/bin/emptyenv, though, I'm surprised
that the script fails with "emptyenv: fatal: unable to exec foreground: No
such file or directory" -- I expected that after emptyenv emptied the
environment, it would then use the default path to resolve the next command
and exec into it. But that doesn't happen!

If I change the first foreground command (line #1) so that it *also* has a
full path /opt/skar/bin/foreground, then the script works just as it does
if /opt/skar/bin is in the PATH when I run the script -- so after emptyenv
exec's into the next program, the default path is definitely being used.
Why isn't it used when emptyenv is running?

Cheers!

Brett

-- 
Brett Neumeier (bneume...@gmail.com)