Re: s6-rc user services on Gentoo

[Guillermo]

El mié, 3 abr 2024 a las 8:37, Laurent Bercot escribió:
>
> >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 polls for readiness using s6-notifyoncheck
> >and a dbus-send command...
>
>   "dbus-daemon --print-address=3" should produce a suitable notification.
> The address of the bus can only be printed once the bus exists. :)

But then, there is a problem if one actually wants the server address
information that --print-address provides. Alexis' 'run' script for
example wants to save that to a file (apparently in a directory
suitable for s6-envdir). If the output is sent to the notification
pipe instead, s6-supervise will 'eat' it while waiting for the final
newline character, and then the information is lost.

And more generally, there's also the question about how 'ready'
dbus-daemon actually is when the point in its code that prints the
server address is reached. I can't really say without looking at the
code; dbus-daemon has many duties once its UNIX domain socket is
bound.

G.

Re: s6-rc user services on Gentoo

[Guillermo]

Hello,

El mar, 2 abr 2024 a las 1:42, Alexis escribió:
>
>   
> S6RC_SERVICE_REPO=${HOME}/src/srht/gentoo-overlay/sys-apps/s6-rc-services/files/
>
> * The above directory contains two service directories:
> ** dbus-session-bus/, containing:
> *** type: longrun
> *** notification-fd: 3
> *** producer-for: dbus-session-bus-log
> *** run:
> #!/usr/bin/execlineb -P
> importas HOME HOME
> redirfd -w 4 ${HOME}/.env.d/DBUS_SESSION_BUS_ADDRESS
> dbus-daemon --session --fork --nopidfile --print-address=4

You already got an answer about why s6-rc-init doesn't work (the scan
directory and the directory of service definitions given to
s6-rc-compile should not be the same; let s6-rc-init populate the
service directory). I'd like to comment on what you didn't ask :)

1) Why are you telling dbus-daemon to --fork? That defeats the purpose
of service supervision. The service definition for the system-wide
message bus that I have on a Gentoo VM of mine with s6 + s6-rc +
s6-linux-init uses --nofork.

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 polls for readiness using s6-notifyoncheck
and a dbus-send command...

> [a] The current s6 and s6-rc pages on the wiki have lot of detail,
> without any "quickstart" tutorials that might make it easy for
> people to get on board.

Most of the content is from around 2017, a time in which the s6 suite
was less known, information in places other than the skarnet.org
website was lacking and inaccurate —despite official documentation,
while being short and to the point, has always been quite good and
complete IMO; it seemed people just didn't bother reading it? [1]—,
and there weren't many usage examples around.

[1] I think I never said it, but what made me look at s6 for the first
time (s6-rc and s6-linux-init didn't exist back then), after seeing a
post in the Gentoo forums, was its documentation ("OK, nice
explanations, let's try this").

Re: gpg-agent runit run script

[Guillermo]

El jue, 29 sept 2022 a las 9:22, Alexis escribió:
>
> João Pedro Malhado writes:
>
> > The Void linux manual shows gpg-agent running as an example, but
> > they
> > don't show
> > the run script, so I don't know how they set it up.
> > https://docs.voidlinux.org/config/services/user-services.html
>
> Duncaen's run script for gpg-agent is here:
>
> https://github.com/Duncaen/dotfiles/blob/master/sv/gpg-agent/run

The combination of Duncaen's run script, and the Void Handbook's
example /etc/sv/runsvdir-/run script, at least if used
verbatim, does not appear to set up GPG_TTY.  gpg-agent might start,
but I'm not sure if things will work well if, e.g., it wants to run
the pinentry program...

G.

Re: gpg-agent runit run script

[Guillermo]

El mar, 20 sept 2022 a las 18:51, João escribió:
>
> I would like to have gpg-agent running under runit supervision on a user
> runsvdir, but I have been unable to write a run script that works.
> Would anyone have an example run script for gpg-agent, or be able to offer any
> pointers?

As already suggested, gpg-agent's --supervised command is probably the
closest thing that would do what you want, but in that case, gpg-agent
will:

* expect to have a properly set up environment, which runit's 'chpst
-e' could do. This includes variable GPG_TTY, which should contain the
name of a valid terminal that the supervision tree would have to make
available.
* expect to receive a bound and listening UNIX domain socket as file
descriptor 3, which runit tools alone can't do (but
s6-ipcserver-socketbinder from s6 can).

Then, also as already mentioned, this command has been deprecated
since GnuPG 2.3.6, so, in my opinion, it's better to just have
gpg-agent started by other GnuPG programs, as the manual says.

G.

Re: s6 xinit replacement?

[Guillermo]

Hello, yianiris / fungal-net

El lun, 23 may 2022 a las 7:07, yianiris escribió:
>
> Unbelievable, on this particular list, someone suggesting that dbus or
> systemd (elogind is the most invasive of all parts of systemd) is needed
> to run X [...]

Oh, I'm not suggesting it, I am stating it as a fact :)

OK, now more seriously. This has come up some time ago in the Gentoo
Forums when Gentoo's 'suid' USE flag changed to unset by default; the
correct (although somewhat simplified for brevity) way to state that
assertion is: the only *officialy supported* way to *not* run Xorg as
root is by having it get open file descriptors from a "logind
provider" (a process that implements the D-Bus org.freedesktop.login1
interface) using file descriptor passing, for /dev special files that
would otherwise require a privileged open() call.

Why? Because that is how Xorg is currently programmed. Technical
details in this old version of a Gentoo Wiki article, if you are
interested:

* 
https://wiki.gentoo.org/index.php?title=Non_root_Xorg=884856#Supported_setups

Personally, I don't mind D-Bus and elogind that much, because they
combine well with an s6-based init system:

  PID COMMAND
1 s6-svscan -X3 -- /run/service
  106 s6-supervise dbus-daemon
  438  \_ dbus-daemon --system --nofork --nopidfile
  480 elogind-daemon

$ s6-rc-db type dbus-daemon
longrun

That said, I know that there are people who do not like D-Bus and / or
elogind, and don't want them installed. That's OK, it's their choice.

> no logind no dbus 0 logind/dbus warning/error messages.

I hope you read the "I suppose that Xorg is not a suid binary" and
"unless you do something else" parts of my previous e-mail. Setups
without a suid Xorg binary, without D-Bus, and without a logind
provider, need to work around the privileged open() situation:

* AFAICT, Void and Obarun build Xorg with '-Dsuid_wrapper=true', so
they install the Xorg suid wrapper, and configure it to never drop
privileges by default.
<https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/template>
<https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/files/Xwrapper.config>
<https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/PKGBUILD>
<https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/Xwrapper.config>

* Samuel adds his user to a group that allows processes to perform the
required privileged open() calls. (What Rio's setup does with respect
to /dev/dri/card* files has not been specified).

All of these require some form of elevated privileges, including
effectively running Xorg as root even if its binary might not be suid
(its helper, Xorg.wrap, is). If your setup works in a way that does
not involve elevated privileges, to be honest, I'd rather read about
*that* instead of yet another systemd / RedHat / IBM rant.

> Again, sorry Guillermo, this is not personal [...]

No worries, no offense taken.

G.

Re: s6 xinit replacement?

[Guillermo]

Hello, Samuel.

El sáb, 14 may 2022 a las 23:44, Samuel Holland escribió:
>
> X is started at boot from my user supervision tree[1], which is started by the
> user-* services in my system supervision tree[2].
>
> [1]: https://github.com/smaeul/rc-user
> [2]: https://github.com/smaeul/rc

I had a look at your s6-rc service definitions, and it seems that you
don't have one for the system-wide message bus (D-Bus) and elogind.
That, in addition to having the tmpfs whose path is stored in
XDG_RUNTIME_DIR mounted by a "user-setup@" system service,
makes me think that you are not running those. On the other hand, IIUC
the Xorg process is part of a supervision tree that runs with your
(unprivileged) user and is launched by service "user-services@", and I suppose that Xorg is not a suid binary, so unless you do
something else, your Xorg*.log file should contain something like:

(EE) systemd-logind: failed to get session: PID  does not
belong to any known session
...
(EE) open /dev/dri/card0: Permission denied
...
(EE) Screen(s) found, but none have a usable configuration.

So, what did you do? Did you also grant your user privileges for
opening the /dev/dri/card* character special files?

Thanks,
G.

Re: s6 xinit replacement?

[Guillermo]

El sáb, 14 may 2022 a las 22:52, Laurent Bercot escribió:
>
> [...] it *is* possible to run Xorg under s6; several users are
> doing so, and I hope they will post their setup.

I actually don't run Xorg as a supervised process. I don't know what
systemd-based GNU/Linux distributions do, but on Gentoo with OpenRC,
Xorg is not started by the init system, it is started either by xinit,
or by a display manager, so I kept it that way.

When using startx from an interactive shell:

  PID TT   EUSERCOMMAND
1 ?root s6-svscan -X3 -- /run/service
  107 ?root s6-supervise agetty@tty1
  515 tty1 root  \_ /bin/login --
  560 tty1 guiller+  \_ -bash
  567 tty1 guiller+  \_ /bin/sh /usr/bin/startx
  584 tty1 guiller+  \_ xinit /etc/X11/xinit/xinitrc
-- /etc/X11/xinit/xserverrc :0 -auth ...
  585 tty1 guiller+  \_ /usr/bin/X ...
  589 tty1 guiller+  \_ /bin/sh /etc/X11/Sessions/openbox
  650 tty1 guiller+  \_ /usr/bin/openbox --startup ...

When using a display manager (SDDM here):

  PID TT   EUSERCOMMAND
1 ?root s6-svscan -X3 -- /run/service
  106 ?root s6-supervise sddm-daemon
  702 ?root  \_ sddm
  704 tty7 root  \_ /usr/bin/X ...
  718 ?root  \_ /usr/libexec/sddm-helper --socket ...
--start /usr/bin/openbox-session ...
  719 ?guiller+  \_ /usr/bin/openbox --startup ...

So only the getty process and the display manager process are
supervised. I'm not sure if supervising Xorg is worth it. Say that
there is a transient event that makes Xorg crash. X11 clients would
likely die because they lost the connection to the X server, and then
xinit would exit, so the screen would just display a shell prompt
again, or the display manager would just spawn the greeter again, so a
graphical login screen would be displayed. If one is running Xorg, it
is likely because one is running a GUI, right? And if one is running a
GUI, it's probably because one is sitting right in front of the
computer, and one would notice the shell prompt / greeter screen, and
just type ''startx' / log in again. I mean, having a GUI on e.g. a
headless server does not seem very useful.

So I'd also be interested in what others think. (Maybe I should get
into this IRC thing :) , and I think I'll reply to Samuel's post
later).

G.

Re: s6 xinit replacement?

[Guillermo]

Hello,

El mié, 11 may 2022 a las 0:43, dallinjdahl escribió:
>
> I tried to run X under s6 with the following run file:
>
> ~~~
> #!/usr/bin/execlineb
> [...]
> X :${screen} vt${screen}
> ~~~
> [...]
> (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted
> (EE)
> Fatal server error:
> (EE) xf86OpenConsole: Switching VT failed
> [...]
> Does anybody know anything about how s6-svscan and s6-supervise might
> change the environment so as to complicate running X?

If the Xorg process does not run as root, the tty specified in the vt
argument must be its controlling terminal. It works if you run X from
an interactive shell (perhaps indirectly through 'startx'), because it
inherits the shell's controlling terminal. It doesn't when run by
s6-supervise, because s6-supervise executes the 'run' file in a new
session, so there is no controlling terminal.

You can see Xorg fail in the same way if you do:

$ setsid startx

Using util-linux' setsid(1), or:

$ execlineb -Pc 'background { s6-setsid startx } exit'

G.

Re: runit: why ignore SIGCONT for stages?

[Guillermo]

This was meant for the mailing list. I accidentally replied to the
author instead. Sorry Leah!

El mar, 23 nov 2021 a las 9:18, Leah Neukirchen escribió:
>
> [...] This seems to be due to runit(8) before execing
> into the stages:
>
>   sig_unblock(sig_cont);
>   sig_ignore(sig_cont);
> ...
>   strerr_warn3(INFO, "enter stage: ", stage[st], 0);
>   execve(*prog, (char *const *)prog, envp);
>
> [...] Can someone explain why?

I guess only the author can provide an authoritative answer, but this
looks like a bug. It is possible that sig_uncatch() was meant here.
That's what the code calls for the other two signals that runit(8)
catches (SIGCHLD and SIGINT).

sig_ignore() makes no sense here, wouldn't that make 'sv cont' useless
for processes of the init system's supervision tree?

G.

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Guillermo]

El vie, 29 ene 2021 a las 14:27, Guillermo escribió:
> [...]

Huh. Lots of apostrophes that shouldn't be there, and that I just
couldn't see without a fixed width font...

G.

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Guillermo]

El vie, 29 ene 2021 a las 0:07, Casper Ti. Vector escribió:
>
> Not using s6-linux-init has never been an explicit goal, [...]
>
> Currently I do not understand the `s6-linux-init-shutdown(d)' way
> well, so the old-fashioned way is retained at least for now, [...]

Forgive me if I'm misunderstanding aspects of the architecture, but
jugdging from a quick look at the Git repository, I *think* that you
could depend on s6-linux-init (the package):

* You could replace /etc/slew'/init/rc.boot with s6-linux-init (the
program), or a wrapper script around it. s6-linux-init does more or
less the same as the current script, except running load_clock.rc
(which you could do in /etc/slew'/init/rc.init).
* You could move the current /etc/slew/run to
/etc/s6-linux-init/current/run-image when installing slew. I'm not
sure what skalibs' hiercopy() would do if the latter is just a symlink
to the former.
* You could replace /etc/slew'/init/rc.halt with a service directory
for s6-linux-init-shutdownd in /etc/slew'/run/service, just like you
do now for the catch-all logger.
s6-linux-init-shutdownd does more or less the same as the current
script, except running save_log.rc, save_clock.rc and calling swapoff.
You can move that to /etc/slew'/init/rc.fin, or
/etc/s6-linux-init/current/rc.shutdown.final if you must do some of it
after killing all processes and unmounting filesystems.
* You could symlink /etc/s6-linux-init/current/rc.{init,shutdown} to
/etc/slew'/init/rc.{init,fin}, perhaps with some minimal
modifications.
* You could replace calls to s6-svscanctl in
/etc/slew'/run/service/.s6-svscan/SIG* with calls to s6-linux-init-hpr
if you want to be able to do e.g. 'busybox poweroff''.
* You could replace /etc/slew'/run/service/.s6-svscan/finish with
something simpler, instead of being a symlink to
/etc/slew/init/rc.halt.

G.

Re: Some suggestions on old-fashioned usage with s6 2.10.x

[Guillermo]

El jue, 28 ene 2021 a las 7:08, Casper Ti. Vector escribió:
>
> I did not actively follow the recent evolution of s6, and have just been
> bitten badly by s6 2.10.x on my Alpine servers (where slew [1] is used
> of course) when it comes along with other updates.
>
> [1] 
> [...]
> it will be nice if the old-fashioned way (with stage 1 and stage 3 as
> static scripts) is supported as well [...]

Out of curiosity, do you have a reason for wanting to keep the
"old-fashioned way"? Is it a goal of your project to depend on s6 and
s6-rc, but not current s6-linux-init? It seems to me that doing so
would be easier. It even looks like you could use the current
/etc/slew/init/rc.{init,fin} scripts (perhaps with minor adjustments)
as s6-linux-init's rc.init and rc.shutdown for slew, respectively.

G.

Re: s6-supervise: use of nosetsid

[Guillermo]

El jue, 3 dic 2020 a las 18:34, Laurent Bercot escribió:
>
>   So, can you juggle fds to avoid nosetsid, or can't you do the same
> thing without it?

This particular use of nosetsid can probably be implemented in some
other way. I did think about having supervision tree processes inherit
a FD for the shell's terminal from s6-svscan, and also about using an
s6-fdholderd process, and having supervision tree processes retrieve
the FD from it. Although I haven't tested either yet.

It seems I missed the addition of s6-svscan's -X option; I saw it one
day in the output of 'ps' on a VM that was using s6-linux-init, didn't
recognize it, but then forgot to look up what it did :P But I would
have to 'tag' messages in some way, so that the catch-all logger
recognizes them and sends them to the terminal, right?

Anyway, nosetsid + /dev/tty is still the simplest implementation, I
have to admit.

G.

Re: s6-supervise: use of nosetsid

[Guillermo]

El jue, 3 dic 2020 a las 13:47, Laurent Bercot escribió:
>
>   I have previously added the "nosetsid" feature to s6-supervise, to
> address the issue: [...]. So when people want to manually
> test a supervision tree, they can have nosetsid files in their test
> service directories, and ^C will send a SIGINT to all the processes
> including the services, so everything will die, which is what they
> want.
> [...]
>   Hence, my question to users: do you have a *valid* reason to use
> nosetsid files in your service directories?

I don't know if it is a valid reason, so I'll just tell what I
remember using these files for, and you judge :)

I happen to be one of those people who test service directories and
s6-rc service definitions by running s6-svscan in a terminal using
's6-svscan &' (and then s6-rc-init with a live state directory that is
not /run/s6-rc, and lots of -l options), and tearing down the
supervision tree using 's6-svscanctl -t .'. So no Ctrl + C in my case.

I remember occasionally using 'nosetsid' files for the convenience of
being able to redirect the output of 'run' and 'finish' to /dev/tty
(the controlling terminal of the shell I used to run s6-svscan) so
that I could see certain messages during tests in which s6-svscan had
its stdout & stderr redirected to a logger (typically, for emulating
an s6-linux-init-like s6-svscan-as-process-1 scenario). I think it was
for doing something like

foreground {
  redirfd -w 1 /dev/tty
  echo "Some message I want displayed on my terminal"
}

Having the supervised processes become session leaders meant that they
lost the controlling terminal, which, for X terminals, would be some
random special file in the devpts filesystem. Redirecting to /dev/tty
would not work in that case.

Granted, it is a rather obscure usage, and not a frequent one in my
case, but your mentioning of notsetsid files triggered the memory, so
I thought I'd mention that.

G.

Re: writing s6 services

[Guillermo]

El mar., 3 nov. 2020 a las 8:48, billa chaitanya escribió:
>
> >So, Is there any variable we can use inside run or finish
> > script of a service equivalent to the pid of the  process started inside
> > run script?

The PID of the supervised process will be the same as that of the
'run' script if it is correctly written, so it's $$ for a shell
script, and the value of the environment variable specified to the
getpid program for an execline script.

* http://www.skarnet.org/software/execline/getpid.html

It is not available inside the 'finish' script, but even if it was, it
is no longer useful since, if that script is being executed, the
supervised process has already terminated, and the PID it had has been
'released'.

G.

Re: Dependencies in S6

[Guillermo]

El mié., 21 oct. 2020 a las 7:10, Amaresh Kotekal escribió:
>
> Secnario 1:
> 1. A & B are one shot services in a s6-rc bundle. Service B is dependent on
> A. ( added in dependency file).
> 2. I think Service B will start after the completion of service A ( A then
> B, in serial manner ) is it correct ? or
> 3. Service B will start immediately after the service A as started (in a
> parallel manner) ?

#2. If A starts successfully, B will be started after A, i.e.
serially. If A fails to start, B won't be started.at all.

> Secnario 2:
> 1. A is one shot service and B is a long run service. Service B is
> dependent on Service A.

Same as scenario #1. Whether B is a longrun or a oneshot does not
change the behaviour.

> Secnario 3:
> 1. A is a long run service and B is a one shot service. Service B is
> dependent on Service A.
> [...]
> 3. Do I need to use notification mechanism if I want to start service B
> after A service as reached particular point in execution

Same as scenario #1, service type does not affect the behaviour. What
does depend on service type is the way s6-rc detects that state
transition has completed, and the way it detects transition failure.
For oneshots, transition completion happens when the oneshot's process
terminates. And transition failure is determined based on the process'
exit code, and, if a timeout was specified with a 'timeout-up' file,
also on whether it terminates before the timeout.

For longruns that support readiness notification, transition
completion happens when the longrun's process notifies readiness. And
if a timeout was specified with a 'timeout-up' file, transition
failure is determined based on whether notification happens before the
timeout.

If there is no support for readiness notification, transition
completion happens when the longrun's process has been spawned by its
corresponding s6-supervise process, because there is no better way. If
the process can be polled for readiness, you can use the
s6-notifyoncheck program to hook to s6-supervise's readiness
notification mechanism.

* http://www.skarnet.org/software/s6/s6-notifyoncheck.html

> Secnario 4:
> 1. A & B both are long run services. Service B is dependent on Service A.

Left as an excercise :)

G.

Re: S6 bundle

[Guillermo]

Hi,

Strictly speaking, you should say "s6-rc bundle", not "s6 bundle".

El mar., 20 oct. 2020 a las 13:00, Amaresh Kotekal escribió:
>
> Contents of S6 bundle will run serially one after the other or they will
> run parallely ?

Specifying the name of a bundle in an 's6-rc -u change' command with
make s6-rc start all services named in its 'contents' file. How they
will start is governed by dependencies (i.e. the contents of those
services' 'dependencies' file), as usual. If no service in the bundle
depends on any of the others, they start in parallel. If some of them
depend on others, you'll have subsets of services that start serially.

> If any one service fails in bundle is other services will continue to run
> or they will be not started ?

Again, this is governed by dependencies. If no service in the bundle
depends on any of the others, whether one service fails or not does
not impact the rest of them. If some service in the bundle depends on
others, and any of those fails, it will not be started, as usual.

G.

Re: Module-load binary for S6

[Guillermo]

Hello,

El vie., 9 oct. 2020 a las 9:19, Amaresh Kotekal escribió:
>
> Is the module-load binary is available for S6 to load all the kernel module
> ?

Just in case the actual question you wanted to ask was "how do I get
functionality equivalent to that of the systemd-modules-load program
with an s6-based init system?": you can use s6-rc and define one or
more oneshots in its the service database.that invoke the modprobe
program.

> Is there any support for volatile binds in S6 ( S6 tool for volatile bind )

What is a "volatile bind"? The only thing I find in a Web search with
that name is something specific to the Yocto Project.

G.

Re: [request for review] Port of s6 documentation to mdoc(7)

[Guillermo]

Hello,

El dom., 30 ago. 2020 a las 7:01, Laurent Bercot escribió:
>
>   That would be totally awesome. However, I'd hold off on s6-rc for now,
> because I'm in the process of exploring a possible redesign (for better
> integration of features that distributions want before packaging and
> using s6-rc), so it's not improbable that all the documentation gets
> rewritten in a not-too-distant future.

I have only seen one new feature committed to the Git repository so
far. Is it too early to ask what are you planning to change?

Thanks,
G.

Re: Runit source version control

[Guillermo]

El dom., 16 ago. 2020 a las 11:56, Érico Nogueira escribió:
>
> I was looking into runit version history, and was wondering if there's
> anywhere I could access actual version control of its source.

There is a Git repository, actually:

git clone http://smarden.org/git/runit.git/

Source: https://www.mail-archive.com/supervision@list.skarnet.org/msg01353.html

G:

Re: Following log directories

[Guillermo]

El sáb., 27 jun. 2020 a las 4:59, Jonathan de Boyne Pollard escribió:
>
> John W Higgins wrote:
>
> > I meant nothing towards s6 - but daemontools does not deal with leap
> > seconds (or at least it cetainly looks that way from my foolish
> > viewpoint).
> >
> daemontools very much *does* deal in leap seconds.  The little-known
> requirement for daemontools, which *is* in its manual and has been all
> along albeit that many people have overlooked this, is that one use one
> of the Olson "right" timezones.

If anyone is interested, decoding the TAI64N timestamps produced by
s6-log with nosh's version of tai64nlocal produces the same result as
doing so with s6-tai64nlocal, and decoding the TAI64N timestamps
produced by nosh's cyclog with s6-tai64nlocal produces the same result
as doing so with nosh's tai64nlocal. At least on my system without a
"right/" timezone.

On the other hand, I just realized that cyclog does not seem to
properly finalize the 'current' file (including the setting of the
execute-by-owner permission) when it exits normally. Perhaps the
destructor of class 'logger' should call logger::flush_and_close()
rather than logger::close()?

G.

Re: Following log directories

[Guillermo]

El jue., 25 jun. 2020 a las 10:20, Guillermo escribió:
>
> El jue., 25 jun. 2020 a las 6:27, Carl Winbäck escribió:
>
> > Does anyone know if the follow-log-directories tool[1] from the nosh
> > suite is compatible with logs produced by s6-log?
>
> Let's find out. I'll test that.

And it appears to be compatible, indeed, as long as s6-log is invoked
with the 't' directive (prepend timestamp in TAI64N format), to match
the logging file format expected by follow-log-directories, as stated
in its documentation.

Also, note that follow-log-directories is a daemon, so it will keep
running and outputting log lines until killed, once it catches up with
the logging directory. TAI64N timestamps are not decoded, so if you
want them in human-readable format, pipe its standard output to
s6-tai64nlocal.

You might also want to separate follow-log-directories's standard
output stream from its standard error stream, since the program is
somewhat chatty during catch-ups and during logdir rotations.

G.

Re: Following log directories

[Guillermo]

Hi,

> Does anyone know if the follow-log-directories tool[1] from the nosh
> suite is compatible with logs produced by s6-log?

Let's find out. I'll test that.

G.

Re: runit SIGPWR support

[Guillermo]

El mar., 25 feb. 2020 a las 6:08, Jonathan de Boyne Pollard escribió:
>
> Laurent Bercot:
> >  Of course, but once the fd is closed, /dev/console should not have
> > any impact on the process, so would a kbrequest still reach it?
>
> Yes.

Also, I tested it :) I added an open2("/dev/tty0", O_RDONLY |
O_NOCTTY) + ioctl() + fd_close() sequence to s6-linux-init.c right
after the reboot(RB_DISABLE_CAD) call, specifying SIGQUIT as the
argument of the KDSIGACCEPT ioctl (to use a signal 'divertable' by
s6-2.9.0.1's s6-svscan), and the SIGQUIT handler does get called
indeed when I press Alt + Up Arrow.

The file descriptor specified in the ioctl() call, as far as I can
tell, is only used by the kernel to check permissions. The ioctl is
allowed if the FD corresponds to the process' control terminal, or if
the process has CAP_KILL or CAP_SYS_TTY_CONFIG capabilities. But the
kernel just seems to record the PID of the invoking process and the
requested signal number. (vt_ioctl() in drivers/tty/vt/vt_ioctl.c).

> First: This is a kernel virtual terminal thing not a console
> thing.  Strictly speaking, it is doing it wrongly to access it through
> the console device, which is not necessarily a KVT.

Yeah, I overlooked this. I suppose it'll work on /dev/console as long
as it is a kernel virtual terminal, but it won't always be the case.
sysvinit and systemd use /dev/tty0 for the ioctl (and sysvinit falls
back to its standard input if that fails), so I used that for the
(second) test.

G.

Re: runit SIGPWR support

[Guillermo]

El lun., 24 feb. 2020 a las 19:49, Laurent Bercot escribió:
>
> So there is no fd to call the ioctl on, and no way for a user to trigger
> a kbrequest.

s6-linux-init has a suitable open file descriptor. It is its standard
input, before it closes it to do the slashdev test.

G.

Re: runit SIGPWR support

[Guillermo]

El lun., 24 feb. 2020 a las 19:25, Laurent Bercot escribió:
>
>   I purposefully did not add a default SIGWINCH handler, because
> sysvinit does not come with a default kbrequest in /etc/inittab.
> I added a SIGPWR handler that performs a regular poweroff because
> it sounds like a sane default for a power failure.

I see. I couldn't tell whether the omission of .s6-svscan/SIGWINCH was
intentional or not.

>  The output of s6-l-i-m is only a baseline, a starting point;
> it can be tweaked for arcane stuff such as non-default shutdown and
> kbrequest.

OK.

G.

Re: runit SIGPWR support

[Guillermo]

The keyboard signal can actually be set to any signal less than or
equal to NSIG with the KDSIGACCEPT ioctl. sysvinit just happened to
pick SIGWINCH for that, and so did systemd and nosh, presumably for
compatibility.

El dom., 23 feb. 2020 a las 20:53, Laurent Bercot escribió:
>
>   Both SIGPWR and SIGWINCH are caught in the latest s6 git head.
>
>   Release coming whenever real life stop throwing things at me and I
> can actually find a week-end to polish things and cut it.

I noticed that you modified s6-svscan to divert SIGPWR and SIGWINCH,
but s6-linux-init-maker only creates a handler for SIGPWR (that just
does 's6-inux-init-shutdown -a -p -- now', like the SIGUSR1 handler).
If you bothered making SIGWINCH 'divertable', you could also add the
KDSIGACCEPT ioctl() call to the stage1 init (s6-linux-init), just like
you did with the reboot(RB_DISABLE_CAD) call, and have
s6-linux-init-maker create a run-image/service/.s6-svscan/SIGWINCH
file.

My suggested action for SIGWINCH would be to execute a file in the
'scripts' subdirectory of the basedir. The skeldir counterpart of this
file could be a shell script with only explanatory comments, just like
the skeldir's rc.shutdown.final (so, by default, unless the
administrator configures something, the keyboard signal would do
nothing).

Since the inittab action field for the keyboard signal is "kbrequest",
the target unit that systemd starts in response to the keyboard signal
is named "kbrequest.target", and the target bundle that nosh's
system-manager starts in response to the keyboard signal is named
"kbrequest", my extremely original suggestion for the script's name
would be... "kbrequest" :)

(Actually, for sysvinit, systemd and nosh, the action in response to
SIGPWR is also configurable, and by default SIGPWR does nothing, so I
don't know what LXC containers do if they include an init system… they
must have some extra configuration I guess).

G.

Re: The "Unix Philosophy 2020" document

[Guillermo]

El sáb., 28 dic. 2019 a las 11:06, Alex Suykov escribió:
>
> Minor note on this. Resource limiting with cgroups does not require
> any explicit support from s6, or any external tools for that matter.
> Literally just `echo $$ > $cg/cgroup.procs` in the startup script
> is enough, assuming the group has been created (mkdir) and the limits
> have been set (bunch of echo's).

Exactly. And that's what nosh's move-to-control-group(1) and
set-control-group-knob(1) do. They are convenience tools invoked by
nosh scripts generated by conversion of unit files (with
'system-control convert-systemd-units'). Nosh's service manager
doesn't directly deal with cgroups, and neither does its PID 1
program.

> The whole thing regarding cgroups in systemd is really about a very
> different problem: supervising broken services that exit early and
> leave orphaned children behind.

I'm not sure if it is specifically for that. AFAIK, it is an
implementation detail of 'KillMode=control-group' and 'KillMode=mixed'
unit file directives. Daemons that use those, like GDM, seemingly
'stay in the foreground', and can therefore be supervised, but spawn
child processes (and/or threads?) that they expect someone else to
kill when they exit.

* https://www.freedesktop.org/software/systemd/man/systemd.kill.html#KillMode=
* https://gitlab.gnome.org/GNOME/gdm/blob/3.34.1/data/gdm.service.in

(A BusName directive and no Type directive means, I think, that the
process can be supervised, and should be considered ready when it
acquires a bus name)

For those cases, I believe only the "read PIDs from cgroup.procs and
kill corresponding processes until no more PIDs are read" part of the
'babysitter' functionality is needed, and IMO that fits better in the
finish file, like in Oliver's example.

As for the "Is there real pressure to have this?" question, I guess it
depends on how many daemons that need o rely on this KillMode
functionality actually exist? Do we know?

G.

Re: The "Unix Philosophy 2020" document

[Guillermo]

El vie., 27 dic. 2019 a las 20:56, Oliver Schad escribió:
>
> Sorry, I have to correct that a bit: you can use the freezer cgroup as
> I did, but there is no guarantee, that you can successfully kill a
> freezed process.

You can't? So the 'kill -9' command in your script might not work
while the cgroup's state is "FROZEN"?

> So you can decide:
>
> 1) race-condition
> 2) unkillallable processes without race-condition

AFAIK systemd does not (and will not?) use the freezer cgroup
controller, so I guess it's 1) in that case :)

* 
https://github.com/systemd/systemd/blob/db9c5ae73e23d816e2df2a3e10a9a2a60b5b3ed7/docs/CGROUP_DELEGATION.md#controller-support

G.

Re: s6 usability

[Guillermo]

El sáb., 21 dic. 2019 a las 6:26, Jan Braun escribió:
>
> > > 1) Debian ships with a working and maintained runit-init package.
> [...]
> > I hear you. Unfortunately, I have no control over what Debian does.
> [...]
> If you're referring to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> then, well, you are fighting against POSIX. There's little choice for
> Debian in the matter. Taking a hardline stance on such "legal" issues is
> part of their identity as a distro.

Trying to accomodate Debian is probably a waste of time at the moment,
until the results of the ongoing General Resolution vote are known
next weekend.

> It's not difficult launching the browser, it's difficult getting to the
> correct webpage. Compare
> | $ elinks /usr/share/doc/s6/s6-log.html

'elinks /usr/share/doc/s6/index.html' and then navigate? :)

> > Would a generic "s6" command, that takes alternative syntax and rewrites
> > itself into "internal" commands, help?
> [...]
> Probably yes, but if you are doing that, then why don't you look at
> argv[0] and provide the runit interface proper? :D

That would create a 'multple personality binary'.

> (Or provide runsv/sv/chpst/.. as individual binaries, since you prefer
> those.)

That could prevent installing both s6 and runit, depending on
packaging, Same as s6 and daemontools[-encore] if the s6- prefix in
program names was dropped.

> > > 4) s6 seems more complex (hello execline!), and I don't (yet?) see any
> > >benefit/feature I'd appreciate except minimizing wakeups.
> >
> > This, on the other hand, is a misconception that really needs to
> > disappear. Understanding execline is *not needed* to run s6.
>
> Needing to *understand* execline wasn't my misconception, nor worry. But
> when I'm told that a runit-lookalike depends on bringing its own
> scripting language along, then that sounds more like systemd and less
> like djb to me. :(
> [...]
> I know you
> want to popularize execline, but "you must use it if you want to use my
> other tools" is not a helpful form of advocacy.

If there is no misconception about the need to understand execline,
then I find this criticism quite odd. It's like complaining that a GUI
application 'imposes' e.g. Qt, or that Xorg 'imposes' X11 video and
input drivers. As long as it is a dependency (i.e. an implementation
detail from the POV of a user), if fail to see the problem. I would
understand if it was e.g. a big and intrusive dependency, or a
dependency that prevented you from installing other packages, but
execline isn't that, so I don't see how this compares to systemd.

> But since you are mentioning it, that was another of my "s6 seems
> more complex" issues. runit goes from "start the supervisor manually" to
> "be pid 1" with very little effort. See runit(8).
> Or https://www.unix.com/man-page/debian/8/runit/ I guess. ;-P
>
> s6-linux-init and s6-rc seem extremely complicated in comparison.

s6 + s6-rc vs runit is not a good comparison. One alternative provides
a service manager, the other one doesn't. Not equivalent feature sets.
s6  + s6-linux-init vs runit would be a better comparison
feature-wise. But, if one takes 1) into account, this is kind of
abstract, because Debian currently packages neither s6-linux-init nor
s6-rc.

G.

Re: The "Unix Philosophy 2020" document

[Guillermo]

El dom., 17 nov. 2019 a las 4:28, Casper Ti. Vector escribió:
>
> A system proponent gave a remark about nosh's `move-to-control-group',
> which appears, to some degree, justified:
> 

Those are just two if statements 'sharing' a body for brevity. That
deals with errors in the openat() and subsequent write() calls, for
the file that controls cgroup membership. By displaying a message
constructed in the same way in both cases, and then throwing an
exception. *Shrug*

As I understand it, throwing the exception is necessary. Not only does
that transfer control directly to main(), destroying all objects with
automatic storage duration in its way, but also main() is written in
such a way that doing so makes the move-to-control-group process exit
with the code contained in the exception object, rather than chain
loading the next program. The error message could be optional, but I'm
sure human users appreciate that there is one :)

G.

Re: s6-log can create current with 640?

[Guillermo]

El vie., 25 oct. 2019 a las 5:22, Dewayne Geraghty escribió:
>
> Results for umask
> rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'redirfd -w 1 /tmp/t1 umask
> 037 echo hello' ; echo $? ; ls -l /tmp/t1
> [...]
> I've placed the ktrace's dumpfile in txt format so its readable for you at
> http://www.heuristicsystems.com/s6-umask/t1.kdump
 42180 execlineb CALL  execve(0x7fffc770,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffc770,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/bin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffc760,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/usr/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffc760,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/usr/bin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffc760,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/usr/local/sbin/redirfd"
 42180 execlineb RET   execve -1 errno 2 No such file or directory
 42180 execlineb CALL  execve(0x7fffc760,0x7fffc830,0x7fffea40)
 42180 execlineb NAMI  "/usr/local/bin/redirfd"
 42180 execlineb NAMI  "/libexec/ld-elf.so.1"
 42180 redirfd  RET   execve JUSTRETURN

> I also tried what I thought was the more logical
> # rm -f /tmp/t1 ; /usr/local/bin/execlineb -Pc 'umask 033 redirfd -w 1
> /tmp/t1 echo hello' ; echo $? ; ls -l /tmp/t1
> [...]
> This ktrace is
> http://www.heuristicsystems.com/s6-umask/t1-umask-redirfd.kdump
   276 execlineb CALL  execve(0x7fffc770,0x7fffc830,0x7fffea40)
   276 execlineb NAMI  "/usr/bin/umask"
   276 execlineb NAMI  "/bin/sh"
   276 execlineb NAMI  "/libexec/ld-elf.so.1"
   276 sh   RET   execve JUSTRETURN
[...]
   276 sh   CALL
openat(AT_FDCWD,0x7fffed10,0x10)
   276 sh   NAMI  "/usr/bin/umask"
   276 sh   RET   openat 3
   276 sh   CALL  fcntl(0x3,F_DUPFD_CLOEXEC,0xa)
   276 sh   RET   fcntl 10/0xa
   276 sh   CALL  close(0x3)
[...]
   276 sh   CALL  read(0xa,0x104c9d0,0x400)
   276 sh   GIO   fd 10 read 160 bytes
   "#!/bin/sh
# $FreeBSD: stable/12/usr.bin/alias/generic.sh 151635
2005-10-24 22:32:19Z cperciva $
# This file is in the public domain.
builtin ${0##*/} ${1+"$@"}
   "
   276 sh   RET   read 160/0xa0

Let me guess: the value of PATH is
/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin,
execline's chain loading umask is in /usr/local/bin, and FreeBSD
happens to have an 'umask' shell script in /usr/bin. If that is
correct, then you'll have to either use the absolute pathname
/usr/local/bin/umask in the execlineb chain, or run it with a PATH in
which /usr/local/bin comes before /usr/bin.

G.

Re: s6-linux-init: Actions after unmounting filesystems

[Guillermo]

El dom., 18 ago. 2019 a las 15:36, Laurent Bercot escribió:
>
> >Simply excluding filesystems doesn't help when the root filesystem is on one 
> >of
> >these devices that needs teardown actions after being unmounted. In that 
> >case,
> >the only workable solution is to have PID1 pivot_root() to a tmpfs with the
> >teardown/reboot tools in it. That way you can actually fully unmount the 
> >former
> >root filesystem.
>
> Are there systems in the real world that actually work like that? That
> need pivoting into a "shutdownramfs" in order to be able to unmount the
> rootfs and perform teardown operations on it? This is doable, of course,
> but sounds too complex and too brittle. You'd need more than a fsck to
> recover after a power loss, for instance.

I know that there are people that have the rootfs on an LVM logical
volume or a LUKS encrypted volume, yes. However, those are specialized
setups. I don't use one myself, I think they are risky, and I don't
know the details, but I think they are handled with a (mandatory)
initramfs. Perhaps someone else knows this better. Our friends from
the systemd project have thought of that as well (the 'shutdownramfs'
would be the initramfs that is kept mounted at /run/initramfs):

* https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface

But I think of this as a separate problem, that maybe also means
revisiting the decision of not having s6-svscan do its finish
procedure. I didn't want to mention all the complicated cases at once
:)

>   Now the fun part for me is to find a way for s6-l-i-umountall to
> leave the proper filesystems mounted. It's not as straightforward as
> it seems: if /dev is a symlink to, say, /mnt/tmpfs/dev, then you want
> to keep /mnt/tmpfs/dev, even if it means you have to keep /mnt/tmpfs.
> But if you have a second dev mount on /usr/local/mychroot/dev, then
> you want to unmount that one, so you can unmount /usr/local. I suppose
> I can count the number of devtmpfs, procfs and sysfs, and only keep
> one of each (the first that was mounted), but I have to think more
> about it to make sure it catches everything.

Why not just leaving all of them alone? s6-linux-init-umountall
already warns about, but then just ignores, umount(2) failures. What
happens if you try to unmount /mnt/tmpfs, and you have a devtmpfs
mounted on /mnt/tmpfs/dev that you have previously skipped?

G.

Re: s6-linux-init: Actions after unmounting filesystems

[Guillermo]

El sáb., 17 ago. 2019 a las 20:01, Laurent Bercot escribió:
>
> - If a filesystem can track all the processes that have a handle on
> it, it is possible to have it be mounted/unmounted symmetrically by
> the service manager.

I don't think there are filesystems that can do that?

> At unmount time, kill the processes that would
> block the unmount operation, then perform the unmount, then run the
> additional commands. In that case it's all done at the service manager
> level, s6-linux-init doesn't have to do anything.

That's OpenRC's approach, except it does not rely on filesystem
features. It just uses 'fuser -m -k'. But it leads to code that's
quite ugly I think, compared to the simplicity of s6-linux-init's
'kill(-1, SIGTERM)' + 'kill(-1, SIGKILL)':

* 
https://github.com/OpenRC/openrc/blob/882c6bf3bcaba6903d9dc593f8ae41e505b4e4e7/sh/rc-mount.sh

(mountinfo is another OpenRC internal command)

> - There could be a hook in the autogenerated stage 4 script, which
> runs a user-provider script, something like rc.shutdown.after-umount.

This is probably better, but I'd also like to hear other opinions.

> I don't much like giving control to a user script at that level, when
> there are no services running and no mounted filesystems, possibly
> not even /proc or /sys,

You'd probably have to make some exclusions in
s6-linux-init-umountall, like Casper said. Maybe parse the fstype
field in /proc/mounts lines and omit sysfs, proc, tmpfs and devtmpfs?
BTW, OpenRC also does exclusions, via --skip-point-regex and
--skip-fstype-regex options passed to mountinfo (see do_unmount
invocations in services localmount and mount-ro). I admit this
complicates s6-linux-init-umountall.

> and when a hang in a user script could
> very well prevent a clean reboot

I haven't thougt of that. Ouch. Maybe a mechanism like the one
s6-supervise uses to limit execution of the finish file in
s6-linux-init-shutdownd, or some shutdown hook runner? I admit it
complicates s6-linux-init-shutdownd :)

> Admins/distros would have to make sure the deactivate_* functions
> only call binaries that are on the root filesystem.

It is obvious to me that it must be that way, but in this era in which
some distributions want to put every executable in /usr/bin and mount
/usr from an initramfs, who knows :P But that's the distribution's
job, I agree.

G.


G.

s6-linux-init: Actions after unmounting filesystems

[Guillermo]

For the 0.4.x.x series of s6-linux-init, the shutdown sequence model
was that s6-svscan replaced itself with a 'stage3 init' that ran as
process 1 until the machine halted, powered off, or rebooted. The
stage3 init was an execline script.

s6-linux-init-1.0.0.0 and later, among other things, has changed the
shutdown sequence model. The new one is that a supervised 'shutdown
daemon', s6-linux-init-shutdownd, performs all shutdown tasks, and
s6-svscan remains process 1 until the machine halts, powers off, or
reboots. s6-linux-init-shutdownd is a C program.

In both models, all processes are killed with a 'kill(-1, SIGTERM)'
call and then a 'kill(-1, SIGKILL)' call, and then filesystems are
unmounted. For the 0.4.x.x series, this is done by having the stage3
init run a program. Because the stage3 init runs as process 1, it
survives the SIGKILL. For s6-linux-init-1.0.0.0 and later, this is
done directly by s6-linux-init-shutdownd. Because
s6-linux-init-shutdownd is part of a supervision tree rooted in
process 1, it is respawned after the SIGKILL, and then completes the
shutdown sequence.

There are certain setups that require doing something after
filesystems are unmounted. Two examples are LVM logical volumes and
LUKS encrypted volumes, but I suppose there must be more cases. In any
such setup, the shutdown sequence would include a 'vgchange -a n'
command or 'cryptsetup close' command after filesystems are unmounted.
Runit-based Void Linux does this in /etc/runit/3:

* 
https://github.com/void-linux/void-runit/blob/0566391df8c9c93f75ad99d94c8a19abe379908b/3#L37

deactivate_vgs and deactivate_crypt are defined in /etc/runit/functions:

* 
https://github.com/void-linux/void-runit/blob/0566391df8c9c93f75ad99d94c8a19abe379908b/functions#L38

Gentoo, and I suppose that other OpenRC-based distributions as well,
leave this to the service manager. OpenRC-provided 'localmount'
service uses 'fuser -m -k' and umount commands in its stop() function
to unmount filesystems, and 'killprocs' service takes care of every
remaining process using OpenRC's internal kill_all command. Gentoo
then adds services named 'lvm' and 'dmcrypt' to OpenRC's boot
runlevel, and service ordering at shutdown, enforced by specifications
in service's depend() functions and OpenRC's runlevels model, is
localmount < root (a no-op) < fsck (a no-op generally) < {lvm,
dmcrypt} < killprocs < mount-ro, where "<" means "precedes" here.

How would something like this fit in s6-linux-init's new shutdown
model? In the old one, just like in runit's case, I suppose it could
be done in 'shutdown hooks' called by the execline stage3 init.
Something like:

foreground {
   redirfd -r 0 shutdown-hooks.conf
   forstdin shutdown_hook
   importas -u shutdown_hook shutdown_hook
   if -nX { $shutdown_hook }
  echo stage3 init: warning: shutdown hook \"${shutdown_hook}\" failed
}

I also looked at Adélie Linux, which currently uses
s6-linux-init-1.0.2.1 + OpenRC if it is configured to do so, and it
seems to copy Gentoo in this case. It also has lvm and dmcrypt OpenRC
service scripts:

* 
https://code.foxkit.us/adelie/packages/raw/b1eb50599e4db7eb4501af75cbbfa22007081ea5/system/lvm2/lvm.initd
* 
https://code.foxkit.us/adelie/packages/raw/49602ddb82f87067bbb945fc2a814a8eb6d6aabe/system/cryptsetup/dmcrypt.initd

I can't verify without actually installing Adélie, but I suppose these
are also boot runlevel services. However, it appears that Adélie's
/etc/s6-linux-init/skel/rc.shutdown just asks OpenRC to enter a custom
runlevel named 'empty'. Because this isn't the shutdown runlevel, if I
understand correctly this would neither stop boot runlevel services,
nor start shutdown runlevel services, so OpenRC's localmount,
killprocs and mount-ro would not interfere with s6-linux-init's
shutdown procedure. But doesn't this also mean that the vgchange and
cryptsetup invocations in lvm's and dmcrypt's stop() functions would
never happen?

G.

Re: killall test run

[Guillermo]

El dom., 19 may. 2019 a las 9:57, Jeff escribió:
>
> OpenRC is known to work with s6-svscan (this is done via the
> /libexec/rc/sh/s6.sh shell script).

That is part of OpenRC's s6 integration feature, and, although on the
surface it looks like a nice thing to have, the implementation of it
launches s6-svscan with start-stop-daemon, which means that:

* s6-svscan is not supervised.
* s6-svscan's standard output and error are redirected to /dev/null,
so logs from services that don't have a corresponding logger go to the
trash can.

Or at least it was like that last time I checked.

> although it is better to start
> s6-svscan from /etc/inittab (directly or - as i prefer - via a starter
> shell/execline script that ensures at least the scandir exists)
> since SysV init can respawn processes anyway (supervised
> supervisor ;-).

That seems to be the route that Adélie has taken. With an execline
script, /lib/s6/s6-svscanboot, configured in an /etc/inittab 'respawn'
entry. This results in a supervised s6-svscan (by sysvinit), and a
supervised catch-all logger.

> i do not know the order
> in which sysvinit processes the inittab entries for a given (SysV)
> "runlevel". do "wait" entries precede "respawn" entries, followed
> by the "once" entries ?

I believe they are processed in line order.

G.

Re: interesting claims

[Guillermo]

El dom., 19 may. 2019 a las 8:24, fungal-net escribió:
>
> [...]
> This is Adélie adelielinux.org
> installation on HD.  Although it is confusing to me how they set this up
> still, after months of following its development (beta3), there is
> sysvinit on the first steps of booting then OpenRC takes over, and then
> s6-supervisor handles everything running.  It is like a fruit punch in
> my eyes.

As far as I can tell, at the moment it has a sysvinit + OpenRC setup,
plus an s6 supervision tree anchored to process #1. Unlike other
distributions, the getty processes are part of the supervision tree,
and placed there by an Adélie-specific OpenRC service in the sysinit
runlevel.

> One of the reasons I am trying to learn more about init in general and
> porting s6 to a different system is to use either Adélie or Void-musl
> and have pure s6 on them.

I believe Adélie is heading towards supporting that.

> Both s6/s6-rc and 66 pkgs are available through void's repositories but
> s6-rc has been modified and I haven't been able to get it to work.

Really? As far as I can tell, Void's s6-rc is the unmodified upstream
package, and Void's 66 is the unmodified package from Obarun's
repository.

> Void uses arch-like /bin /sbin --> /usr/bin, Adélie has more traditional
> 4 separate directories.

Yeah, that's both /usr-merge and bin-sbin merge. A whole discussion in itself.

G.

Re: interesting claims

[Guillermo]

Hi,

El vie., 17 may. 2019 a las 8:22, fungal-net escribió:
>
> OpenRC: Nice,
>   init
>|_ zsh
>   when I exited the shell there was nothing but a dead cursor on my screen

May I ask what was this setup like? You made a different entry for
sysvinit, presumably with the customary getty processes configured in
/etc/inittab 'respawn' entries, judging by your results, so how was
the OpenRC case different?

> sysV: init and 6 ttys with shell ... nothing can kill it that I know off.

Thanks,
G.

Re: what init systems do you use ?

[Guillermo]

El jue., 2 may. 2019 a las 21:53, Jeff escribió:
>
> what init systems do this list's subscribers use ?

I have a Gentoo setup with no initramfs and one of the stable desktop
profiles (in the 'eselect profile' sense, which means GNU libc with
dynamic linking), that allows me to boot with an assortment of init
systems using the GRUB2 menu:

* sysvinit + OpenRC, using agetty from util-linux, to get a fully
functional system with one of the distribution's officially supported
configurations.
* runit + OpenRC, again using agetty from util-linux, to get a
somewhat restricted system for experimentation. Gentoo packages runit,
and OpenRC gets used because it is invoked by the supplied
/etc/runit/{1,3} files. Notable drawback: OpenRC's service scripts in
the sysinit and boot runlevels may launch unsupervised daemons that
runit doesn't know about.
* s6 + s6-rc, with version 0.4.x.x s6-linux-init-style scripts, again
using agetty from util-linux, to get an even more restricted system
for experimentation. OpenRC is inactive in this case, since s6-rc is
the service manager.
* nosh, with agetty replaced by a combination of the package's tool,
to get the same restricted system as for s6 + s6-rc. OpenRC is also
inactive in this case, since nosh contains a service manager (in the
skarnet.org documentation sense).

The "restricted system" scenarios would be less restricted, of course,
if I wrote, o grabbed and adapted from somewhere else, enough service
definitions for the selected init system, to match the sysvinit +
OpenRC configuration, but that means work of course.

G.

Re: s6-log problem with +regex

[Guillermo]

Hi,

El jue., 9 may. 2019 a las 22:03, Dewayne Geraghty escribió:
>
> My test comprised an input /tmp/af with the intention of
> four separate s6-log managed logdirs. The logdirs' structure was
> correctly created, however three contained the same content, and the
> default contained nothing.  So the reduced form of testing looks like this:
> # cat /tmp/af   # a file of text to be processed
> a line of text not selected
> b nother line of text
> c more lines
> [date] with line of text
>
> The intention is to create a separate log based on a regex of the first
> character.

Did you want something like this (in shell)?

/usr/local/bin/s6-log - +^a /tmp/a-only - +^b /tmp/b-only - +^c
/tmp/c-only - +^\\\[ /tmp/date-only - f /tmp/default  The following places the content of /tmp/af into /tmp/date-only.
>
> #!/usr/local/bin/execlineb -P ; # The testing script
> redirfd -r 0 /tmp/af
> /usr/local/bin/s6-log -b n3 +^\\\[ /tmp/date-only  f s100 S1500 T
> /tmp/default

Yes, because at the beginning of directive processing, all input lines
are implicitly selected. Therefore, a '+' directive does nothing if
there aren't any '-' directives preceding it that deselect something:
anything it selects is already selected.

> The following works correctly, in that date-only does not contain the
> [date] line.  It does contain the rest of /tmp/af, while /tmp/default
> does contain only the date (input line).
>
> # cat s6-test.sh
> #!/usr/local/bin/execlineb -P
> redirfd -r 0 /tmp/af
> /usr/local/bin/s6-log -b n3 -^\\\[ /tmp/date-only  f s100 S1500 T
> /tmp/default

Yes, because at the beginning of directive processing, all input lines
are implicitly selected, and then the '-' directive deselects those
that start with '[', so /tmp/date-only contains everything except
those lines. The 'f' directive selects lines that start with '[',
because, quoting the documentation, those are the ones "that have not
yet been acted upon (i.e. that were always deselected when the script
encountered an action directive)", so /tmp/default contains only them.
The "action directive" that "acts upon" the other lines in this
context is '/tmp/date-only' (an automatically rotated logdir
directive).

> Incidentally using the s6-log command
> /usr/local/bin/s6-log -b n3 +^\\\[ /tmp/date-only  s10 S150 T +^b
> /tmp/b-only  f s100 S1500 T /tmp/default
> results in both
> /tmp/date-only/current and /tmp/b-only/current
> containing all of /tmp/af, /tmp/default had the expected structure but
> empty current file.

Yes, same as the first example. '+' directives that aren't preceded by
'-' directives that deselect something do nothing, therefore
/tmp/date-only and /tmp/b-only are copies of /tmp/af. And because
there are no lines "that have not yet been acted upon" (all of them
have been "acted upon" by the '/tmp/date-only' and '/tmp/b-only'
directives), the 'f' directive selects nothing and /tmp/default is
empty.

> PS I haven't made sense of the hyphen in the example, after "E500 - " on
> page https://www.skarnet.org/software/s6/s6-log.html.

It deselects all lines.

>  Testing resulted in
> s6-log: fatal: unrecognized directive: -

Oh? It works for me...

G.

Re: further claims

[Guillermo]

El mar., 30 abr. 2019 a las 5:55, Laurent Bercot escribió:
>
> >haven't you claimed process #1 should supervise long running
> >child processes ? runit fulfils exactly this requirement by
> >supervising the supervisor.
>
> Not exactly, no.
> If something kills runsvdir, then runit immediately enters
> stage 3, and reboots the system. This is an acceptable response
> to the scanner dying, but is not the same thing as supervising
> it. If runsvdir's death is accidental, the system goes through
> an unnecessary reboot.

If the /etc/runit/2 process exits with code 111 or gets killed by a
signal, the runit program is actually supposed to respawn it,
according to its man page. I believe this counts as supervising at
least one process, so it would put runit in the "correct init" camp :)

There is code that checks the 'wstat' value returned by a
wait_nohang() call that reaps the /etc/runit/2 process, however,
it is executed only if wait_exitcode(wstat) != 0. On my computer,
wait_exitcode() returns 0 if its argument is the wstat of a process
killed by a signal, so runit indeed spawns /etc/runit/3 instead of
respawning /etc/runit/2 when, for example, I point a gun at runsvdir
on purpose and use a kill -int command specifying its PID. Changing
the condition to wait_crashed(wstat) || (wait_exitcode(wstat) != 0)
makes things work as intended.

G.

Re: interesting claims

[Guillermo]

El lun., 29 abr. 2019 a las 16:46, Jeff escribió:
>
> "suckless init is incorrect, because it has no supervision capabilities,
> and thus, killing all processes but init can brick the machine."
>
> a rather bold claim IMO !
> where was the "correct" init behaviour specified ?
> where can i learn how a "correct" init has to operate ?
> [...]
> there is actually NO need for a "correct" working init implementation
> to provide respawn capabilities at all IMO.

This was discussed in the mailing list, you'll be able to find
relevant messages in the archives, and the last part of the sentence
you quoted should clarify what "correct" means in this context. But to
recap:

* A failure mode is identified (the machine becomes unusable and
requires a hard reboot), along with the condition that triggers it
(death of all processes except #1).
* The condition can be triggered explicitly with a kill(-1, SIGKILL)
call in a process with root privileges, so by definition it is not an
impossible condition, but this is not the only way to trigger it.
Processes can die for a variety of reasons.
* An program with "respawn capabilities" running as process 1 can
avoid entering this failure mode, a program that does not have the
capabilities, cannot.

Nothing more, nothing less. This is not a statement about how likely
this failure mode is, only that it exists. An init system can or
cannot choose to prevent it, this is a design choice (and usage of
"correct" will give you an idea of what the author of this particular
software package thinks), and a person may or may not decide to use an
init system that doesn't, this is a matter of preference.

G:

s6-linux-init-1.0.0.0 (was: special s6-svscan/perp(d) catch-all logger service option)

[Guillermo]

Hi,

El jue., 25 abr. 2019 a las 20:10, Laurent Bercot escribió:
>
> I would recommend you to grab the 0.4.0.1 release of s6-linux-init
> and use the stage 1 scripts created by s6-linux-init-maker, either as
> is, or as a source of inspiration for your own stage 1 scripts.
> [...]
> I would also recommend you, or anyone interested in stage 1 script
> creation, to do this sooner rather than later, because a new version
> of s6-linux-init is going to be released in less than a week, and [...]
> stage 1 will be a C program rather than an
> execline script,

I saw this a couple of days ago in the Git repository. So, what's your
stance on the (soon to be) 'old' execline stage1, stage3 and
.s6-svscan/SIGxxx files approach? Will you consider it deprecated, or
just an alternative to the s6-linux-init-1.0.0.0 approach? Are the
version 0.4.0.1 s6-linux-init-maker scripts going to be preserved
somehow, for inspiration as you say?

Thanks,
G.

Re: s6 problems logging

[Guillermo]

Hello,

El dom., 27 ene. 2019 a las 15:56, Sean MacLennan escribió:
>
> So it seems that s6-log does not like buffered output.

It probably isn't that it doesn't like it, but that it doesn't even
get to see the output. As Jonathan also pointed out, when you run
doorknob using a supervision suite, stdout is redirected to a pipe,
which is not an 'interactive device' (unlike an interactive shell's
controlling terminal) so it is fully buffered. And at least GNU libc's
implementation of the  interface buffers indeed. A smaller
program that does your vprintf() + putchar('\n') sequence exhibits
this behaviour, and adding an fflush(stdout) call solves it. But...

> I modified
> doorknob to vsnprintf into a buffer and then tried various output
> methods.
>
> 1. puts(msg) Failed as expected (basically the same as vprintf).
>
> 2. write(1, msg, strlen(msg)) Worked! So non-buffered ok.
>
> 3. fputs(msg, stderr) Then add `fdmove -c 2 1' to the run file works!
>So fdmove seems to fix things up. Which is probably why most people
>don't see this problem.
>
> Obviously, for 2 and 3 I did a strcat(msg, "\n").
>
> So I think I will go with 2, but to stderr to follow Jonathan de Boyne
> Pollard's comment "Unix conventions: Logs go to standard error".

If you want minimal changes and follow the convention of logging to
stderr, you could have done vfprintf(stderr, fmt, ap) + fputc('\n',
stderr), which also works. stderr is never fully buffered.

G.

Re: s6-ps

[Guillermo]

El sáb., 5 ene. 2019 a las 7:46, Jonathan de Boyne Pollard escribió:
>
> * https://packages.debian.org/sid/s6

And buster too. Which has the side effect of making it automatically
available in Devuan ceres and beowulf :)

* https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=s6_2.7=any

I don't know why execline is a 'recommends' though. It should be a
'depends', I believe.

G.


G.

nosh: User-space virtual terminal test and questions

[Guillermo]

Hello,

So, I've gotten around to testing user-space VTs with nosh tools on
Gentoo, as described in the nosh Guide. Mostly console-fb-realizer,
but I also tested console-termio-realizer on a kernel VT for
comparison. This was in a VirtualBox VM, so there were two framebuffer
devices available: the one provided by the VirtualBox Guest Additions
'vboxvideo' kernel module (vboxdrmfb), and the kernel's VESA
framebuffer device (vesafb). The combination of vboxvideo with
console-fb-realizer was explosive, I got a (guest) kernel panic. But
console-fb-realizer with the VESA framebuffer device worked, as did
console-termio-realizer. "Worked" meaning that I could log in and get
an interactive shell using the user-space VT.

For ease of troubleshooting I wanted a minimal setup instead of the
full-blown one of nosh-bundles and the external formats import
subsystem. I left the Gentoo standard agetty processes on /dev/tty1 to
/dev/tty6 alone, and had console-fb-realizer or
console-termio-realizer take /dev/tty8, and communicate directly with
console-terminal-emulator via /run/dev/vc1, with neither a multiplexor
(at first) nor an input method front-end processor. I also set up the
customary TUI login service using vc-get-tty and open-controlling-tty,
and managed to deal with the BSDness of the requirements on font and
keyboard map files with the help of FreeBSD's SVN repository :)

So now the questions:

1) What is the proper way (if any) to switch between kernel VTs and
user-space VTs? What I found out:
  * console-multiplexor-control with a numeric command and the active
kernel VT, or just 'tty', as the vtname, could switch to a different
kernel VT, just like Alt + function key.
  * console-multiplexor-control with an '8' command and the active
kernel VT, or just 'tty', as the vtname, and Alt + F8, could both
switch to to the user-space VT, with both realizers.
  * With console-termio-realizer, Alt + F1 in the user-space VT could
switch back to the first kernel VT, but I expected that it would
likely work, given that this arrangement is a terminal realized on
another terminal.
  * With console-fb-realizer, Alt + F1 did nothing but print "WARNING:
Unknown input message" on /dev/console. The messages were probably
coming from console-terminal-emulator, as I supposed (and tested
later) that this is designed to switch from a user-space VT to
*another* user-space VT, if console-fb-realizer is communicating with
a console-multiplexor process.

So that left 'console-multiplexor-control 0@tty1', which did switch to
the first kernel VT... but only if run as root. Looking more closely,
it seems that when a kernel VT is specified as the vtname,
console-multiplexor-control is just a wrapper around an ioctl() call
with a VT_ACTIVATE command, which apparently works on Linux for an
unprivileged process if the VT is its controlling terminal. And for a
user-space VT it isn't, just like it isn't either for an X11 terminal
like rxvt-unicode. So, is there an alternative to
console-multiplexor-control as root?

2) Key combinations with Alt (e.g. Alt + f or Alt + b to move forward
or backward one word on Bash) did not work with neither
console-fb-realizer nor console-termio-realizer. Any idea why, or does
this just happen to me?

3) More strangely, Ctrl + x (e.g. to exit from GNU nano) did not work
with console-termio-realizer, but did with console-fb-realizer. Other
key combinations with Ctrl worked fine. Any idea why, or does this
just happen to me?

4) With console-termio-realizer, green is blue and blue is green :D
Not with console-fb-realizer, though. Any idea why, or does this just
happen to me?

Thanks,
G.

Re: Log rotation issue with runit

[Guillermo]

El sáb., 29 dic. 2018 a las 15:33, Dmitry Bogatov escribió:
>
> > > And this issue happens not only on crash, it happens after every
> > > termination of svlogd, due any signal. I would agree that SIGKILL is
> > > crash, but issue reproduces with SIGINT and SIGTERM.
> >
> > SIGTERM should make svlogd exit cleanly, are you sure? It does for me,
> > and when restarted, does not create any .u file (using Gentoo's runit,
> > which is upstream runit plus a minor patch to the makefile).
>
> Wierd. I tried again, and failed to reproduced issue with SIGTERM this
> time.

Good. This is the expected behaviour of SIGTERM.

> What do you mean, `supervision tree not not being teared down properly'?

First of all, I should have written "not being torn down properly" :P
With "properly" I mean with all runsv and runsvdir processes exiting
cleanly.  Either by sending runsvdir a SIGHUP signal, which makes it
take care of its runsv children, of by sending runsvdir a SIGTERM
signal and then making all runsv processes exit one by one with 'sv
exit' (or SIGTERM, which is equivalent). Each runsv will then close
the writing end of the logger's pipe before exiting, if there is one,
making the logger finalize the 'current' file, set its permissions to
0744, and exit as well (because it detects EOF in its stdin). So next
time svlogd is started, no .u file. I know this to work as described
on Gentoo.

If runit is the init system, process 1 sends a SIGTERM signal to the
runsvdir process that /etc/runit/2 replaces itself with during the
shutdown sequence, so it is the task of /etc/runit/3 to make
supervised processes exit, as well as their runsv supervisors.
Debian's runit-2.1.2-19 'stock' /etc/runit/3 file is this one, right?

* 
https://salsa.debian.org/runit-team/runit/raw/a45cbc4ec73e1e293d372147ad5ab3f1d2a9/debian/contrib/3

Here, the 'sv exit /etc/service/*' that follows 'sv force-stop
/etc/service/*' takes care of making the runsv processes exit. The bug
reporter's /etc/runit/3 is a modified one, so that's what I would look
next.

G.

Re: Log rotation issue with runit

[Guillermo]

El jue., 27 dic. 2018 a las 10:47, Steve Litt escribió:
>
> [...] Simply run a program, invoked by cron,
> that deletes .u files over a certain age, as long as it doesn't delete
> the latest .u file.

Daemontools-style loggers like svlogd delete files themselves during a
rotation for a reason,..

> [...] If Debian doesn't yet have an s6 package,
> perhaps a packager could be found, and a Debian s6 (and s6-rc) package
> can be made.

It does. In buster and sid. Alas, no s6-rc (yet).

G.

Re: Log rotation issue with runit

[Guillermo]

El jue., 27 dic. 2018 a las 6:36, Dmitry Bogatov escribió:
>
> And this issue happens not only on crash, it happens after every
> termination of svlogd, due any signal. I would agree that SIGKILL is
> crash, but issue reproduces with SIGINT and SIGTERM.

SIGTERM should make svlogd exit cleanly, are you sure? It does for me,
and when restarted, does not create any .u file (using Gentoo's runit,
which is upstream runit plus a minor patch to the makefile).

IMO, the bug report shows way too many .u files, this should be a rare
occurence. Ideally, there should be none. And according to the
timestamps, at least two or sometimes all three loggers are producing
a .u file at about the same time, as if they had been started
together.

> Init: runit (via /run/runit.stopit)
> [...]
> Versions of packages runit recommends:
> ii  runit-init  2.1.2-19
> [...]
> -- Configuration Files:
> /etc/runit/3 changed [not included]

What does this mean? Is this Debian with runit as the init system and
a modified /etc/runit/3 instead of the one supplied with the Debian
package?

I'm going to make a guess here and say that the supervision tree is
not being teared down properly, resulting in svlogd processes not
exiting cleanly and producing lots of .u files, compounded with the
fact that they are never deleted during rotations because of the fix
to bug #878476...

G.

Re: Log rotation issue with runit

[Guillermo]

> […] Both .u and .s files are supposed to
> be deleted when they are the oldest file in the logging directory, to
> honor 'u' lines in 'config' files, […]

Sorry, that should have read: to honor 'n' lines in 'config' files.

G.

Re: Log rotation issue with runit

[Guillermo]

El mar., 25 dic. 2018 a las 10:39, Dmitry Bogatov escribió:
>
> Hello!
>
> I am Debian maintainer of `runit' supervision suite. Recently, I
> received bug report [^1] about stray .u logfiles. After some
> investigation I found code, that caused issue, but it seems that it was
> written with some purpose, yet I fail to understand that purpose.
>
> Author Gerrit Pape directed me here. Any clarification would be welcome!
> Please keep bug in thread.
>
> [^1] https://bugs.debian.org/916230

It was likely written on purpose. A 'current' file that doesn't have
the execute by owner permission set is not considered to completely
processed, and becomes a .u file instead of being appended to. As has
been said, it can happen if svlogd does not exit cleanly. Although it
doesn't seem to be mentioned in svlogd's man page, this comes from
daemontools' multilog program, which inspired svlogd:

* https://cr.yp.to/daemontools/multilog.html (section "Automatically
rotated logs")

On the other hand, it seems to me that the patch used for resolution
of bug #878476 prevents all .u files from being deleted, so they would
indeed accumulate indefinitely. Both .u and .s files are supposed to
be deleted when they are the oldest file in the logging directory, to
honor 'u' lines in 'config' files, and this is only a problem when the
one about to be fed to a processor happens to be the one chosen for
deletion because of a wonky clock. This issue was brought up earlier
in this mailing list, and a different patch was suggested:

* https://www.mail-archive.com/supervision@list.skarnet.org/msg00667.html

This one seems to do the right check, maybe it should have been applied instead?



G.

Re: More Answers

[Guillermo]

El lun., 24 dic. 2018 a las 7:10, Laurent Bercot escribió:
>
> >* https://unix.stackexchange.com/a/489949/5132
> >
> >This may be of interest to people looking for some (brief) comparative 
> >analysis.  Including the further reading.  (-:
>
>   Thanks for the heads-up! I posted an answer in complement to yours.
>
>   We really need to settle on some terminology. I don't like your
> use of "service manager" to mean "supervision system", and your use
> of "system manager" to mean what I call a "service manager" is meh.
>
>   I'd be okay to ban the "service manager" terminology entirely because
> it's confusing, and use "supervision system" and "state manager" (which
> sounds better than "system manager" to me) instead. Thoughts?

I also find clearer and personally prefer the terminology used in the
skarnet.org documentation. The 'service/machine state manager' and
'process supervision suite/system' distinction captures details such
as that the former takes into account service interrelationship
(service dependency being the first form of it that comes to mind),
whereas incarnations of the latter I know of do not (by themselves).
But 'service manager' ("something that manages services") is in too
widespread use to be banned :P I have no problem with the term being
used to designate something like OpenRC or s6-rc, though.

The 'system manager' and 'service manager' terminology is used in
systemd documentation (as in "systemd is a system and service manager
for Linux operating systems", found in the man page for the systemd
program), although I don't know if the terms are given some specific
definition somewhere or just used generically.

I'm not sure that what is being described in the Stack Exchange answer
as the "system manager rôle" maps to a service manager in the s6-rc
sense. Especially the "generally is run as process #1" because "the
kernel of the operating system treats it specially, sending it
information about system state change requests" part. And the fact
that it is being applied to nosh's system-manager program and to the
van Smoorenburg init program. System state changes are mentioned, but
two aspects are involved: triggering them in response to something and
actually performing them. I read the answer as mostly referring to the
former?

I mean, with a sysvinit + OpenRC setup, it is indeed process 1, the
init program, that triggers a state change (e.g. by spawning a child
process configured in /etc/inittab in response to Ctrl + Alt + Del or
the administrator using the shutdown program), but the openrc program
that performs it (by executing service scripts in /etc/init.d). With
an s6 + s6-rc setup, it is process 1, s6-svscan, that triggers a state
change (e.g. by spanwing .s6-svscan/SIGINT or .s6-svscan/SIGUSR1
processes in response to Ctrl + Alt + Del or the administrator using
the s6-poweroff program from s6-linux-init), but the s6-rc program
that performs it. And with a nosh setup, it is process 1,
system-manager, that triggers a state change, but its system-control
child processes that perform it. Using the skarnet.org definitions,
service-manager, the program, is a process supervisor (of multiple
process rather than just one like s6-supervise, or at most two, like
runsv), and the service manager concept is implemented by
system-control :D Or rather, a subset of its subcommands that includes
'start' and 'stop'.

I'll also point out that OpenRC does have a PID 1 program since
version 0.25 named openrc-init, and an accompanying openrc-shutdown
program. BUT... it has the problem of not supervising some other
process, and therefore making the machine unusable and in need of a
reboot if all processes except #1 die. I don't know of any
distribution that doesn't use OpenRC in combination with something
else as the PID 1 program, though, at least as a supported/default
setup.

G.

Re: Noclobber supervisor/init installation

[Guillermo]

Hello,

El sáb., 27 oct. 2018 a las 16:12, Steve Litt escribió:
>
> So I've created the following terminology:
>
> du: Daemons used. Refers to the symlink directory or its
> subdirectories. /service in the original daemontools is an example
> of a du directory. /etc/sv in both Void Linux and Debian and Devuan
> is an example. In Devuan I'd make this directory /etc/du/runit.
> There could later be an /etc/du/s6 or /etc/du/daemontools.

This one already has a name: scan directory (the pathname argument
runsvdir is invoked with). However, I believe that this is
/run/runit/runsvdir/current on Void, and /etc/service on Debian, not
/etc/sv. In the first case, that's a symbolic link to
/etc/runit/runsvdir/current so that one can use runsvchdir(8):

* http://www.smarden.org/runit/runlevels.html

In the second case, that's a symbolic link to
/etc/runit/runsvdir/default apparently?

If so, your proposed location would differ from that of Debian
stretch's and buster's runit package, and therefore currently Devuan
ASCII's and Beowulf's, right? Wouldn't Devuan have to fork the package
to change the convention then?

* https://packages.debian.org/stretch/amd64/runit/filelist
* https://packages.debian.org/buster/amd64/runit/filelist

> da: Daemons available. Refers to the directory housing the real-file
> directories that are symlinked in the du directory. Material in the
> da galaxie is site-modifiable to accommodate site specific needs.
> In Devuan I'd make this directory /etc/da/runit. There could later
> be an /etc/da/s6 or /etc/da/daemontools.
>
> dp: Daemons packaged. Refers to a directory housing unmodified
> material straight from the runit_daemons package. The dp directory
> shall consist of a directory holding daemon directories for every
> daemon in the collection. The daemon directories shall not contain
> any supervise file, directory or symlink, nor any log files or
> directories meant to hold log files,  nor any other stateful
> things. The intent of the dp directory is that its material is
> modified ONLY by later packages, never on-site. It's therefore
> entirely read-only. In Devuan I'd make this directory /etc/dp/runit.
> There could later be an /etc/dp/s6 or /etc/dp/daemontools.

I usually call these 'service directory repositories', and I believe
on both Void and Debian that is a single directory, /etc/sv, managed
by the package manager, just like /etc/init.d. Again, wouln't changing
the convention set up by Debian packages require a fork?

* https://packages.debian.org/stretch/all/getty-run/filelist
* https://packages.debian.org/buster/all/getty-run/filelist

> runit_tool -i daemonname sees whether the dp version of the daemon dir
> matches the da version, and if so, does nothing. If different or da
> version is missing, it first backs up the existing dp version then
> overwrites it. If the now backed-up dp version matches the da version,
> the da version is assumed not to be custom, and the new dp version
> overwrites the da version. If the backed-up dp and the da differ, it
> assumes the da version is customized, and via backups and warnings,
> walks the user through his/her choices.
>
> runit_tool -e daemonname creates a symlink of the da in du. If nothing
>to symlink to, issues a warning.
>
> runit_tool -d packagename removes that symlink. If no symlink,
>issues a warning.
>
> runit_tool -u daemonname issues a warning and refuses to act if
>there's currently a du->da symlink. If the da version of the daemon
>doesn't match the dp version, issues a warning about it being
>customized, and makes the user strenuously opt in to deleting the
>daemon directory from da. Does not affect dp at all.

Doesn't this overlap functionality (in a contradictory way) with
update-service(8) (a Debian addition to runit)?

* 
https://salsa.debian.org/runit-team/runit/raw/master/debian/contrib/update-service

G.

Re: has anyone gotten nosh to build on Void Linux?

[Guillermo]

2018-07-01 8:38 GMT-03:00 Jonathan de Boyne Pollard:
>
> For the sake of other readers: note that it is not the build system that
> employs the wall program.  (That would be bizarre.)  It is the shutdown
> program, at runtime, as described in its manual.

Yep, that is a runtime dependency rather that a buid-time dependency,
but worth mentioning, because util-linux's build system doesn't build
wall if the 'configure' script is passed a --disable-wall option, and,
for example, Gentoo does not have that program unless explicitly
requested by the administrator with the 'tty-helpers' USE flag.

G.

Re: has anyone gotten nosh to build on Void Linux?

[Guillermo]

2018-06-30 21:27 GMT-03:00 Chris Brannon:
>
> Sorry, I didn't have time to reply, but I made a good deal of progress
> earlier today, after writing to the list.

Great!

> I also needed to fine libtinfo, because
> Void doesn't have it.  Void could probably have libtinfo provided by
> their curses package with a fairly straightforward change.
> I figured out how to get libtinfo from ncurses by looking at the Arch
> PKGBUILD for ncurses.

Depending on how ncurses is built, libtinfo isn't actually needed.
ncurses' build system makes a libncurses library that may come in two
variants: one that only has the narrow character functions, and
another that has both the narrow character and the wide character
functions. You get the latter if ncurses' 'configure' script is passed
an --enable-widec option, and this also renames the library as
libncursesw. This means that libncursesw is essentialy libncurses with
more code, so it has everything libncurses has.

ncurses' build system can also split parts of libncurses out to
separate libraries, one of them being libtinfo, "the termlib library".
You get a libtinfo if the 'configure' script is passed a
--with-termlib option. This means that without that option, libncurses
/ libncursesw has everything libtinfo has. Debian chooses to build
libtinfo, Gentoo does not unless requested by the administrator with
the 'tinfo' USE flag, and Void seems to choose to not build it. If
that is the case, however, instead of trying to produce a libtinfo
somehow, you could just patch nosh's source/system-control.do and
source/system-manager.do scripts (they are shell scripts): change the
lines that do the tinfo=-ltinfo assignment with tinfo=-lncurses. I do
something like this on Gentoo.

> > would also help to know what the ID and VERSION_ID fields of Void's
> > /etc/os-release look like. I believe the former is 'void', and the
> > latter is absent, correct?
>
> That's right.

Good. There are some .do scripts that parse /etc/os-release and have a
case ... esac command that tests for different values of those fields.
They are used by redo to build some service bundle directories (nosh's
native format of a 'service definition') and components of the
configuration import subsystem, and are detailed in the aforementioned
"Packages and Ports" chapter of the nosh Guide. If you can figure out
what should go in new void:*) lines, maybe that might get included
upstream :)

Cheers,
G.

Re: has anyone gotten nosh to build on Void Linux?

[Guillermo]

Hi,

2018-06-30 5:44 GMT-03:00 Chris Brannon:
>
> When I run package/compile from the root of the unpacked source tree, I
> get:
> redo: ERROR: all: Cannot find .do file to use.
>
> -- Chris

The nosh-1.37 source package? If you unpacked the source tarball in a
directory named 'nosh-1.37', you have a 'source' and a 'package'
subdirectory, you ran package/compile, but it *did not* create a
subdirectory named 'build', then, as people have said, most likely you
don't have an implementation of pax(1) installed. It is a
POSIX-specified utility, but on most [GNU/]Linux distributions you
have to manually install some package to get it. I believe on Void
that would be the 'pax' package.

Not related to redo's error message, but because distributions differ
in the way they package ncurses and util-linux, you might want to
check if:

* The libtinfo, libncursesw and libuuid libraries are present in
Void's 'standard' libraries directory.
* There is a curses.h file in both Void's 'standard' headers directory
and in a subdirectory named 'ncursesw' (for the narrow character and
wide character versions of the library, respectively). Normally, that
would be /usr/include/curses.h and /usr/include/ncursesw/curses.h.
* The wall(1) program is available in Void's 'standard' executables directories.

Because that's what nosh's build system and executables are going to
expect, as far as I know. If not, patches will probably be needed. It
would also help to know what the ID and VERSION_ID fields of Void's
/etc/os-release look like. I believe the former is 'void', and the
latter is absent, correct?

It would be interesting to see what is needed for different OSes to
make nosh build. If you do try again, please report :)

Hope that helps,
G.

s6-rc live state and database format upgrades

[Guillermo]

Hello.

I was recently reviewing the instructions for the s6-rc dabatase
upgrade procedure, and they made me wonder what would happen if:

* s6-rc-format-upgrade was called with a compiled database that is not
the exact 0.4.0.x equivalent of the one currently associated with the
live state directory (i.e. other that a database created with
s6-rc-compile from version 0.4.0.x and the exact same service
definitions).

* s6-rc-update from version 0.4.0.x was called with a live state
directory currently associated with a <=0.3.0.0 database.

Is any of these things capable of trashing s6-rc's live state? I think
that the documentation is clear about the upgrade procedure, but that
these could be likely ways of accidentally screwing it up. Something
like the latter was actually the database upgrade procedure for
previous backwards-incompatible s6-rc upgrades, right? Although I
don't know if any of them involved a database format change.

Also, I'm lost about the role of version 0.3.0.1:

* https://www.mail-archive.com/skaware@list.skarnet.org/msg01096.html
* 
https://git.skarnet.org/cgi-bin/cgit.cgi/s6-rc/tree/doc/upgrade.html?h=real_0.3.0.1

Development of 0.3.0.1 was done in the skarnet.org Git repository in a
'real_0.3.0.1' branch. Development of 0.4.0.0 was done in the master
branch, and the current upgrade notes don't even mention 0.3.0.1:

* http://www.skarnet.org/software/s6-rc/upgrade.html

So, in the end, does upgrading from 0.3.0.0 to 0.4.0.x require an
intermediate 0.3.0.1 s6-rc-compile + s6-rc-update step, and then
0.4.0.x s6-rc-compile + s6-rc-format-upgrade, or not?

(I didn't have running services that I had to preserve, so personally
I didn't need any special care and just upgraded from whatever I had
at the time to s6-rc-0.4.0.0, but s6-rc-format-upgrade is now there
and one might need to explain or remind correct usage :) )

Thanks,
G.

Re: [announce] execline-2.5.0.0

[Guillermo]

2018-04-02 7:39 GMT-03:00 Laurent Bercot:
>
>  User reports have come in by the hundreds and they are almost
> unanimous (sorry, Colin): they don't like the 2.4.0.0 change,
> pretending it hurts readability (as if), and writability too,
> of execline scripts. (What? People were actually writing execline
> scripts? Why haven't I heard of them before yesterday?)
>  They want a revert to the old syntax.
>
>  Users. They never know what they want.

My reaction:

1) "Oh, an announcement!" (timezone magic made this happen on Saturday for me)
2) "Wait, what? Whaaat?!"
3) All of this chaotically over a short period of time:
  * "How is something like this execline-2.4.0.0 and not execline-3.0.0.0?"
  * "Wait, is s6-linux-init still going to work? Did I miss a new
s6-linux-init release announcement?" (I don't know why my brains
focused on s6-linux-init instead of the major breakage of s6 and s6-rc
that not retaining the old names somehow would have produced)
  * "Wait, did he rename the C source files too? Like
src/execline/=.c, src/execline/;.c, etc.?"
  * "Wait, execline commands exist as executable files in the
filesystem, are the files going to actually have those names? Like
'test' and '['? That new makefile is going to be quite interesting..."
  * "Wait, are programs still going to be callable by their old names?"
- "How? Compatilibity symlinks? Didn't he dislike multiple
personality binaries? Is execlineb going to implement the conversion
as part of its parsing?" (the latter could actually work?)
- "Does every execline script need to be rewritten now? How many
of those are out there already?"
  * "Hmmm, using execline commands from a shell is going to be hell
now with all that character escaping."
  * "Well, on the other hand, maybe no more ImageMagick-like name collisions..."
  * "Let's see how many programs kept their names. Huh? ímport is still here?"
4) "I definitely have to take a closer look now."
5) "Oh."

G.

Re: G++ warnings for set-control-group-knob from nosh-1.37

[Guillermo]

2018-03-11 20:57 GMT-03:00 Jonathan de Boyne Pollard:
>
> The macro generates no warning in the GNU C library in Debian 9, but I
> should have caught that overload that was not passing by reference.  It is
> fixed now, thank you. The in-development source archive for 1.38 is in the
> usual place.

Yes, both G++ warnings are gone now. BTW, the removal of the macros
from  has already been committed, so it looks like it is
going to happen for GNU libc version 2.28:

*  
https://sourceware.org/git/?p=glibc.git;a=commit;h=e16deca62e16f645213dffd4ecd1153c37765f17

However, a new warning has appeared:

In file included from set-control-group-knob.cpp:23:0:
popt.h:85:16: warning: 'virtual bool
popt::table_definition::execute(popt::processor&, char, const char*)'
was hidden [-Woverloaded-virtual]
   virtual bool execute(processor &, char c, const char * s);
^~~
popt.h:100:16: warning:   by 'popt::top_table_definition::execute'
[-Woverloaded-virtual]
   virtual bool execute(processor &, const char * s);
^~~

I believe this is because the 1.38 development version dropped a
'using table_definition::execute;' declaration from the definition of
class popt::top_table_definition that was present in 1.37, so the
three parameter version of popt::table_definition::execute() would now
be hidden. I only did a quick 'redo set-control-group-knob.o' test, so
I'm not sure if it is important or if it affects anything, though.

Thanks,
G.

Re: nosh version 1.37

[Guillermo]

2018-02-20 16:13 GMT-03:00 Jonathan de Boyne Pollard:
>
> Guillermo:
>>
>> redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done.
>> redo-ifchange[2]: ERROR: services/dbus-daemon.service: Not done.
>> redo-ifchange[2]: ERROR: services/system-wide.conf: Not done.
>> redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done.
>> redo-ifchange[2]: ERROR: convert/per-user/at-spi-dbus-bus.service: Not
>> done.
>> redo-ifchange[2]: ERROR: convert/per-user/gconfd.service: Not done.
>> redo-ifchange[2]: ERROR: convert/per-user/per-user.conf: Not done.
>
> A snapshot of the 1.38 development is in the usual place.  See how far that
> gets you.

Farther, but not to the end:

redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done.
redo-ifchange[2]: INFO: services/dbus-daemon.service: Redone.
redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done.
redo-ifchange[2]: ERROR: services/system-wide.conf: Not done.
redo-ifchange[2]: INFO: convert/per-user/at-spi-dbus-bus.service: Redone.
redo-ifchange[2]: INFO: convert/per-user/gconfd.service: Redone.
redo-ifchange[2]: INFO: convert/per-user/per-user.conf: Redone.
redo[1]: ERROR: all: Not done.

Oh, look!

$ grep gentoo source/services/*do source/convert/per-user/*do
source/services/dbus-daemon.service.do: gentoo:*)  ext=debian-linux ;;
source/convert/per-user/at-spi-dbus-bus.service.do: gentoo:*)
ext=redhat-linux ;;
source/convert/per-user/gconfd.service.do: gentoo:*)  ext=redhat-linux ;;
source/convert/per-user/per-user.conf.do: gentoo:*)  ext=linux ;;

I could not spend much time looking into that myself once the weekend
was over, but these look like the correct choices. Did someone else
help with that? Well, I don't actually have the gconf and at-spi2-core
packages installed at the moment, but looking at their ebuilds and the
gnome2 eclass, it does look like Gentoo goes with upstream's defaults,
so gconfd-2 and at-spi-bus-launcher would be indeed in /usr/libexec,
like for RHEL / CentOS apparently.

As for the missing .do scripts, if you are going to go this route:

services/dbus-broker.service.do should symlink dbus-broker.service to
dbus-broker.service.debian-linux
systemd/service-manager.socket.do should symlink
service-manager.socket to service-manager.socket.debian-linux
services/system-wide.conf.do should symlink system-wide.conf to
system-wide.conf.linux

G.

Re: nosh version 1.37

[Guillermo]

2018-02-18 20:05 GMT-03:00 Jonathan de Boyne Pollard:
>
> Guillermo:
>
>> This is going to happen for every [GNU/]Linux distribution that is not
>> Debian, Arch, CentOS or RHEL. It does not... uh... look very portable :/
>>
>
> That is a reflection of reality.  It isn't very portable.  But you are
> misidentifying what it is.
> [...]
> Guillermo:
>
>> Additionally, the convert/per-user/*.do scripts' 'read_os' function calls
>> 'exec' via absolute path /bin/exec instead of relative path ../../exec,
>> which is not going to work if nosh isn't already installed (chicken and
>> egg).
>>
>
> There's no chicken and egg problem.  The external formats configuration
> import requires (amongst others) the nosh-exec package.
> [...]
> Moreover that is not the relative path from your
> $HOME/.config/service-bundles/convert/ directory to /bin.  Not that there
> of course *is* a stable single relative path for such a thing, given that
> home directories can be anywhere from /export/home/guillermo to
> /var/lib/mysql .  Nor that, as mentioned, such a relative path is needed,
> given that one installs the toolset before running the external
> configuration import.

But wait. You are talking here about run-time requirements / behaviour
of the configuration import subsystem and the service bundles provided
by nosh, after one installs (some equivalent of) the nosh-bundles or
nosh-run-via-systemd packages for the target operating system. I
accept that OS-specific patches might be required here and there to
make them work for the reasons you mentioned.

But the 7 .do scripts I talked about are executed (indirectly) by the
package/compile script from the source package, and they just create
symbolic links. To be precise, they are executed by the source/all.do
script, because they are named in 'echo' commands that feed their
output to the 'xargs -r redo-ifchange' invocation. As it is, on any
[GNU/]Linux distribution that is not Debian, Arch, CentOS or RHEL,
downloading the source package and building it slashpackage-style by
executing package/compile will simply fail.

There are warnings in the jdebp.eu webpage about package/stage, but my
expectation was that package/compile would just work (even without a
previous nosh installation), as it has for older versions, provided
the required dependencies are installed (meaning redo, xmlto, ncurses,
pax, etc.). I can work around this by just patching source/all.do so
that it does not execute those .do scripts, or look at what they
should do for Gentoo and patch them, or whatever, but I am sure quite
a few people besides me are going to be surprised by package/compile
failing for them.

(You are right about relative path ../../exec being wrong, it should
be relative to redo's working directory, i.e. ./exec)

G.

Re: nosh version 1.37

[Guillermo]

2018-02-18 3:49 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.37 .
> [...]
>Per-user management has been augmented, finally fixing the problem
>of |system-control| locating the per-user manager by giving the
>per-user manager an optional listening FIFO open file descriptor,
>which it uses to listen for user-wide state change commands.
>|system-control --user| |halt|/|normal|/|sysinit|/ now send
>commands via this FIFO, and each user's |user-services@/username/|
>service bundle now uses |fifo-listen| to set up the FIFO and creates
>the |per-user-manager/| subdirectory in |/run/user|.

\O/ \O/ \O/

On the other hand, all those new .do scripts that generate systemd
unit files and configuration files using the read_os shell function
fail on Gentoo :-P

redo-ifchange[2]: ERROR: services/dbus-broker.service: Not done.
redo-ifchange[2]: ERROR: services/dbus-daemon.service: Not done.
redo-ifchange[2]: ERROR: services/system-wide.conf: Not done.
redo-ifchange[2]: ERROR: systemd/service-manager.socket: Not done.
redo-ifchange[2]: ERROR: convert/per-user/at-spi-dbus-bus.service: Not done.
redo-ifchange[2]: ERROR: convert/per-user/gconfd.service: Not done.
redo-ifchange[2]: ERROR: convert/per-user/per-user.conf: Not done.

'read_os ID' returns 'gentoo' for Gentoo's /etc/os-release, and
'read_os VERSION_ID' returns nothing (it is a rolling release
distribution), so this always matches the

*)   ext=who ;;

lines, making the redo-ifchange invocation fail with either "Don't
know what to use to build this" or "Cannot find .do file to use". Or
making it call convert/per-user/default.do and *then* failing. So what
do I do, should I patch the .do scripts to include a 'gentoo:*)' line?

This is going to happen for every [GNU/]Linux distribution that is not
Debian, Arch, CentOS or RHEL. It does not... uh... look very portable
:/

Additionally, the convert/per-user/*.do scripts' 'read_os' function
calls 'exec' via absolute path /bin/exec instead of relative path
../../exec, which is not going to work if nosh isn't already installed
(chicken and egg). On my computer that results in accidentally calling
execline's exec program, which is even funnier.

Thanks for your attention.
G.

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Guillermo]

2018-01-16 13:09 GMT-03:00 Charlie Brady:
>
> Now seeing these many times:
>
> /usr/include/curses.h:843:31: error:   initializing argument 1 of 'char*
> tigetstr(char*)' [-fpermissive]
>
> service-status.cpp:148:21: error: invalid conversion from 'const char*' to
> 'char*' [-fpermissive]
>s = tigetstr(setaf);
> [...]
>  This is on CentOS7 build platform.

This should be fixed in nosh 1.37. So, unless there were other
compiler errors (warnings are nonfatal), nosh binaries should now
build on CentOS too.

G.

Re: nosh build problems (Re: Compatibilities between runit and s6 (re: )

[Guillermo]

2018-01-16 17:51 GMT-03:00 Jonathan de Boyne Pollard:
>
> Charlie Brady:
>
>> /usr/include/curses.h:843:31: error:   initializing argument 1 of 'char*
>> tigetstr(char*)' [-fpermissive]
>>
>> service-status.cpp:148:21: error: invalid conversion from 'const char*' to
>> 'char*' [-fpermissive]
>> s = tigetstr(setaf);
>
> This is a problem that I thought was confined to OpenBSD, and its
> not-|const|-correct ncurses library.  Certainly this has never been a
> problem on Debian nor on FreeBSD, and M. Caravia did not report any lack of
> |const|-correctness on Arch Linux.

Neither has been a problem on Gentoo. However...

>  What does line 843 of your
> |/usr/include/curses.h| actually say?  Because that's not the location of
> that function declaration in that header in either Dickey ncurses or Acton
> pdcurses as far as I can see.  So what curses are you actually using?

Dickey ncurses' 'configure' script has options --enable-const and
--disable-const. When ncurses is built with --disable-const,
tigetstr()'s parameter has type char *, when built with
--enable-const, it has type const char *. When neither is specified,
default is --disable-const for ncurses 5, and --enable-const for
ncurses 6.

On my computer:

$ grep -E '(define NCURSES_CONST|tigetstr)' /usr/include/curses.h
#define NCURSES_CONST const
extern NCURSES_EXPORT(char *) tigetstr (NCURSES_CONST char *);  /*
implemented */

I can't check what is the case for CentOS, asuming it ships Dickey
ncurses, but I could bet...

G.

Re: New reboot flag: -c for 'power cycle'

[Guillermo]

2017-10-29 22:24 GMT-03:00 Guillermo:
>
> [...] or to call a program that does this reboot(RB_POWERCYCLE) thing
> on FreeBSD, if it's implemented.

Scratch this part; it would have to be called by the stage3 init, not
the SIGWINCH handler. But it was an example, the rest of the message
still stands.

G.

Re: New reboot flag: -c for 'power cycle'

[Guillermo]

2017-10-29 18:01 GMT-03:00 Laurent Bercot:
>
>  Maybe, if it's needed. SIGWINCH is not POSIX, and I'd rather not have
> s6 exhibit different behaviours on systems where it's not supported
> (same reason why I'm reluctant to add pid namespace support to
> s6-supervise). If there's a way to make it entirely transparent, why not.

It looks like there might be. It could be handled just like SIGUSR1
and SIGUSR2 currently are: no-operation for 's6-svscan -S', execute a
diverted signal handler for 's6-svscan -s'. The system-specific policy
is encoded in the handlers (in this case, in a hypothetical
.s6-svscan/SIGWINCH handler if the corresponding mechanism existed),
which aren't provided by s6.

s6-linux-init-maker on the other hand can continue to not generate a
SIGWINCH handler, since there is no sensible default, but IIUC for
's6-svscan -s' a diverted signal with no handler is also a
no-operation, so no observable behaviour change here. However, an
administrator or distribution can provide a handler, e.g. to match
whatever its sysvinit or systemd SIGWINCH policy is, as encoded in
their shipped /etc/inittab or /usr/lib/systemd/system/kbrequest.target
files, or to call a program that does this reboot(RB_POWERCYCLE) thing
on FreeBSD, if it's implemented.

And skalibs' sig_name() already knows about SIGWINCH on OSes that
define it in .

G.

Re: New reboot flag: -c for 'power cycle'

[Guillermo]

(Quoting this e-mail for context)

2017-10-29 5:37 GMT-03:00 Jonathan de Boyne Pollard:
>
> Since SIGWINCH to process #1 is already taken by Linux, I have adjusted my
> softwares to use SIGRTMIN+7 and SIGRTMIN+17 for the signals to process #1
> for this, ready for when Linux eventually catches up with this idea.  (-:

Which reminds me, are there any plans to add SIGWINCH to the set of
signals that 's6-svscan -s' can divert?

G.

Re: execlineb's import conflicts with ImageMagick

[Guillermo]

Hello,

2017-10-22 18:01 GMT-03:00 Jean Louis:
>
> The ImageMagick software has the "import" command
> that is conflicting with "import" from execlineb
> package.

This is known, see the 'execline-2.3.0.0' section of this announcement:

* https://www.skarnet.org/cgi-bin/archive.cgi?2:msp:1687:blbgbjnpebcmhkmelgjd

G.

Re: s6-svscanboot, how to exit?

[Guillermo]

2017-07-14 13:00 GMT-03:00 Jean Louis:
>
> However, the VPS servers don't have much option
> left to me, I can install my own system with s6,
> or I can use the ready Debian, Ubuntu and similar.

OK, quick summary if you are stuck with systemd but want the least
possible interaction with it, and a supervised s6-svscan process.
Untested because I don't have access to a systemd machine and am not
planning to, but it is what I would try.

Assuming you have s6 and execline binaries in /command and the s6 scan
directory in /service, as your OP implies:

1) Copy the s6-svscanboot script from the 'examples' subdirectory of
the s6 source tarball to /command. That execline script starts a
supervision tree with a catch-all logger implemented with s6-log,
which you will probably prefer over the systemd journal, but you need
a service directory for it.

2) Install the s6-linux-init package, and do as root:

s6-envuidgid xxx s6-linux-init-maker -b /command -l /service -U yyy

Where 'xxx' is the efective user you want the catch-all logger to run
as. A new subdirectory with the name you specify as 'yyy' will be
created in your working directory.

3) Copy the directory named 's6-svscan-log' from yyy/run-image/service
to /service. *Do that preserving ownership and permissions!* That is
your catch-all logger service directory.

4) Copy the directory named 'uncaught-logs' from yyy/run-image to
/service. *Do that preserving ownership and permissions!* That is the
s6-log logging directory where your supervision tree messages will go
to instead of systemd's journal.

5) Delete the 'redirfd -w 2 /dev/console' line from
/service/s6-svscan-log/run, since s6-svscan will not be running as
process 1. The catch-all logger's error messages will go to systemd's
journal.

6) Put this as /service/.s6-svscan/finish (unless you want to do more there):

#!/command/execlineb -P

# That is a capital 'X'
foreground { s6-svc -X /service/s6-svscan-log }
exit 0

That will make the catch-all logger and its s6-supervise parent exit
cleanly when the supervision tree is stopped

7) Create a /service/.s6-svscan/env environment directory with the
environment variables you want the supervision tree to run with. It
should at least contain PATH, because s6-svscanboot contains an 'exec
-c' command that will wipe the environment inherited from systemd.

8) Make a /etc/systemd/system/s6-svscan.service service unit file
(/etc/systemd/system because it is an administrator-supplied unit
file):

[Unit]
Description=Supervised s6-svscan

[Service]
#Type=simple is the default
ExecStart=/command/s6-svscanboot
Restart=always
#Could also be Restart=on-failure

[Install]
WantedBy=multi-user.target

After all of this (as root probably):

systemctl enable s6-svscan.service should configure systemd to start
the supervision tree each time the machine boots.
systemctl start s6-svscan.service should start the supervision tree manually.
systemctl stop s6-svscan.service should stop the supervision tree manually.

G.

Re: nosh version 1.34

[Guillermo]

Hi,

2017-07-05 17:41 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.34 .

So, system-control has a new but undocumented
'is-service-manager-client' subcommand?

G.

Re: Why /command ?

[Guillermo]

2017-07-01 20:37 GMT-03:00 Steve Litt:
>
> So I was wondering what the original intent was in having these two
> directories directly off the root? Is it so the init and supervision
> can proceed even before partition mounts are complete? Is there some
> other reason?

It has been mentioned in passing in other replies (and extensively in
other threads of this mailing list), but the answer is: Daniel J.
Bernstein's slashpackage convention.

* http://cr.yp.to/slashpackage/management.html
* http://cr.yp.to/slashpackage/versions.html

(And everything else in http://cr.yp.to/slashpackage, really)

> Can anyone recommend setups that fulfill the reasons for
> the direct-off-root dirs without having direct-off-root dirs?

At first sight I don't see anything wrong with Debian stretch's
packaging of runit. The list of files looks like it has all the needed
components, it respects the FHS layout, and depends only on the libc,
so probably can work on Devuan without modifications.

* https://packages.debian.org/stretch/runit
* https://packages.debian.org/stretch/amd64/runit/filelist

(Well, I hate /usr/bin and /usr/sbin for files that might be
components of an init system; if /usr is a separate filesystem it
needs an initramfs. But then again, binary-based distributions can't
probably boot without one anyway, unless the user compiles its own
kernel)

As the WWW page says, "complete init replacement needs to be done by hand":

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536

Maybe you could help the Devuan project by trying document how to do
*that*. Package runit-init seems to have been dropped, and I can't
find its list of files in Debian's WWW package database. But judging
by what the bug report says, it was broken indeed (messages #10 and
#39 to me are the ones that more clearly explain why).

G.

Re: s6 as a systemd alternative

[Guillermo]

2017-06-29 1:43 GMT-03:00 Steve Litt:
>
> On Wed, 28 Jun 2017 22:31:12 -0300 Guillermo wrote:
>>
>> But then you end up with an unsupervised runsv process, disconnected
>> from the rest of the supervision tree...
>
> I'm not sure about the unsupervised part of it, but I know if the
> executable ends another one is run within a second, and I know that you
> can turn the executable on and off with
>
> sv [up|down] /var/svlink/gnumeric

The executable (gnumeric) is supervised, the supervisor (runsv) is
not. Sure, all those things are true, but while the supervisor is
alive. Kill runsv (if launched in this way) and see what happens.

There is a situation just like this with OpenRC's supervise-daemon.

G.

Re: s6 as a systemd alternative

[Guillermo]

Hello,

2017-06-26 12:05 GMT-03:00 Istvan Szukacs:
>
> [...] I do not want
> logging, ntp and all the other crap that got sucked into it. I understand
> that service files are much better that shell scripts and this is a good
> argument but it does not justify the idiocracy that systemd became in the
> recent years. Ideally we could have a service (like s6) that does only that
> keeping the best parts of systemd as well. This would allow me to run
> redhat/centos based systems and use service files without being worried
> that a huge amount of CPU cycles going to a service that sole purpose is to
> keep services up that actually provide the functionality that I need. Does
> this clarify?

I'm partially repeating what others have said, but the way I see it:

You seem to be focused only on systemd unit files. An alternative init
system that understands unit files doesn't work as a drop-in
replacement.

1) systemd, the package, is not 'just' an init system. It is a whole
set of low-level userland components, that happens to include among
them a program intended to run as process 1 (also named 'systemd').
Some of the components can work without systemd (the program) being
process 1, like systemd-udevd, and maybe libsystemd (I don't know for
sure). Others, like systemd-logind, cannot. And software packages may
depend on any of those components. For example, GNOME desktop
components do not actually care about the init system, but do want to
be able to send messages over D-Bus to a server implementing the
logind API (as far as I understand).

2) Package dependencies and binary-based distributions. A lot of
software packages that have a real dependency on systemd (a package
that only provides a unit file does not qualify as having a
dependency), have an optional compile-time one (e.g. './configure
--with-systemd'). But if developers of a GNU/Linux distribution choose
to build the package with the option turned on, it becomes a mandatory
runtime dependency for the user. Maybe the dependency is on a
component that doesn't care who's process 1 and you are lucky, or
maybe not. And if that is done with every package shipped by the
distribution, the result is an entanglement with systemd you can't get
out of. So once a binary-based distribution decides to get married to
systemd, I think it is safe to assume that it is a one-way ticket.

So it might be possible to have GNU/Linux and not systemd, but highly
unlikely (IMO) if we are talking RHEL or CentOS.

> # rpm -q --requires openssh-server | grep systemd | sort -u
> libsystemd.so.0()(64bit)
> libsystemd.so.0(LIBSYSTEMD_209)(64bit)
> systemd-units
>
> I am not sure why any service would depend on these. Is there functionality
> in libsystemd.so.0 that an ssh service actually needs?

If that's the software from www.openssh.org, Gentoo's packaging of it
[1] does not list systemd as a dependency, not even conditionally on a
USE flag. I'm guessing that what is shown here is some indirect
dependency through PAM.

G.

[1] https://packages.gentoo.org/packages/net-misc/openssh

Re: s6 as a systemd alternative

[Guillermo]

2017-06-28 14:40 GMT-03:00 Steve Litt:
>
> On Mon, 26 Jun 2017 14:53:50 + "Laurent Bercot" wrote:
>>
>>   The problem with the runit model is that it is pure supervision -
>> it does not provide service management. You have to run all your
>> oneshots _before_ you can start longruns.
>
> Not necessarily true. You can easily run longruns early by creating a
> second service directory and a second link directory. You make the
> service specific directory, create run script and the supervise
> directory within it, and symlink like the following:
>
> ln -s /etc/sv2/gnumeric /var/svlink/gnumeric
>
> Then do the following:
>
> runsv /etc/svlink/gnumeric

But then you end up with an unsupervised runsv process, disconnected
from the rest of the supervision tree...

However, regarding Void Linux and udevd, as far as I can tell by
having a quick look at their GitHub repository, it is launched
unsupervised from /etc/runit/1 just to populate /dev, but then that
process is stopped using 'udevadm control --exit', and a supervised
one is launched. Probably the best possible solution if constrained by
the runit model...

G.

Re: Problems with Step 4

[Guillermo]

Hi,

2017-06-27 16:51 GMT-03:00 Daniel GSJ:
>
> Once stage 2 is reached, the computer hangs in the same way than when
> executing *agetty* in an active console tty, and doesn't login neither.
>
> My o.s. is build with Linux-from-scratch, and is running SystemV, so it is
> a pretty simple system.
>
> I've tried different possibilities like:
>
> #!/bin/sh
>
> exec setsid /sbin/agetty tty5 linux
>
> or
>
> #!/bin/sh
>
> exec chpst -P /sbin/agetty tty5 linux

'chpst -P' from the runit package and setsid from the util-linux
package do the same thing. And this works on my Gentoo machine (using
a minimal setup with almost nothing else running, for testing
purposes). Of course, I have to press CTRL + Alt + F5 to get a login
prompt, otherwise I just see the kernel's and runit's messages. You do
not provide enough context about your problem, e.g. you do not say
where your /etc/runit/1 comes from (did you write it yourself? did you
copy one from somewhere? official instructions from
www.linuxfromscratch.org only mention sysvinit or systemd, so it is
not from there), how you know the stage 2 is reached, what you see on
the console when everything hangs, ...

/root/scan/getty-tty1:
total 8
-rw-r--r-- 1 root root0 Jun 28 20:11 down
-rwxr-xr-x 1 root root   48 Jun 28 20:03 run
drwx-- 2 root root 4096 Jun 28 20:07 supervise

/root/scan/getty-tty5:
total 8
-rwxr-xr-x 1 root root   48 Jun 28 20:03 run
drwx-- 2 root root 4096 Jun 28 20:09 supervise

/root/scan/getty-tty1/run:
#!/bin/sh
exec chpst -P /sbin/agetty tty1 linux

/root/scan/getty-tty5/run:
#!/bin/sh
exec chpst -P /sbin/agetty tty5 linux

  PID  PPID  PGRP COMMAND
1 0 1 runit
  674 1   674 runsvdir -P /root/scan log: 
  675   674   675  \_ runsv getty-tty1
  676   674   676  \_ runsv getty-tty5
  677   676   677  \_ /bin/login --
  682   677   682  \_ -bash
  685   682   685  \_ ps axf -o pid,ppid,pgrp,args

And after doing 'sv up ./scan/getty-tty1' and CTRL + Alt + F1, I can
log on tty1 too:

  PID  PPID  PGRP COMMAND
1 0 1 runit
  674 1   674 runsvdir -P /root/scan log: 
  675   674   675  \_ runsv getty-tty1
  687   675   687  |   \_ /bin/login --
  693   687   693  |   \_ -bash
  694   693   694  |   \_ ps axf -o pid,ppid,pgrp,args
  676   674   676  \_ runsv getty-tty5
  691   676   691  \_ /sbin/agetty tty5 linux

G.

Re: A dumb question

[Guillermo]

Hi,

2017-05-02 6:32 GMT-03:00 Francisco Gómez García:
>
> May 2, 2017 8:35 AM, "Steve Litt" wrote:
>
>> I also am surprised you could get Gnome to work without systemd. Just
>> for fun, try out LXDE, and install dmenu and have it at the ready
>> with an easy hotkey. I think you'll love the productivity
>> enhancement, once you get used to it.
>
> Yes, GNOME works, and on its entirety! No missing features on Void so
> far but GNOME Software (because of xbps and PackageKit, naturally).
> Who could have guessed that they didn't need to enforce their init of
> choice to make the desktop of their dreams?

I'm going to bet that's thanks to elogind:




Cheers,
G.

Re: nosh version 1.33

[Guillermo]

2017-04-09 16:52 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.33 .
>
> [...]
>
> More packages
> -
>
> There are now four more -shims packages, for commands whose names conflict 
> with
> commands from other packages: nosh-kbd-shims, nosh-bsd-shims, nosh-core-shims,
> and nosh-execline-shims.

Is this so that package managers can alert users when they try to
install packages with these conflicts? If yes, then the
nosh-execline-shims* packages should also have fdmove(1) and exec(1).
I'm aware that the latter is special because it is the name of one of
the binaries created by the build system (and conveniently allows one
to get a compile-time implementation of setlock(1) by performing
'./exec setlock'); I manage to install both nosh and execline on my
own machine by installing nosh's exec binary as /bin/nosh and making
/lib/nosh/exec a link to /bin/nosh (among other tweaks), so that
/bin/exec is the execline program. The 'chain to a different
personality of the same binary' magic going on inside exec_terminal()
even spares me from having to prepend /lib/nosh to PATH or using
absolute paths inside nosh scripts :)

I'm surprised that if this route is being taken, there aren't any
nosh-daemontools-shims* packages, or something like that, containing
envdir, envuidgid, setlock, setuidgid, softlimit, svc, svok, svscan,
svstat, svup, tai64n and tai64nlocal. AFAICS, Debian, the Arch User
Repository (AUR) and Gentoo all have a daemontools package with
conflicting names after all (and both the AUR and Gentoo also have a
daemontools-encore package).

I'm also looking at the recent package/stage script. It seems that
every program and program alias created by package/compile in
${src}/command/ is installed to some  ${dest}/nosh-*/ directory,
except the aliases disable, enable, preset, reset, show and show-json,
so no binary packages will contain them. I'm not sure if this is
intentional, and it is a minor thing, but I though I should mention it
as well.

Thanks,
G.

Re: nosh version 1.31

[Guillermo]

2017-01-22 14:29 GMT-03:00 Guillermo:
>
> $ tai64nlocal /run/system-manager/log/current
> [...]
> 2017-01-21 22:11:17.709678664 system-manager: ERROR:
> /sys/fs/cgroup/systemd//cgroup.subtree_control: No such file or
> directory
> 2017-01-21 22:11:17.709683364 system-manager: ERROR:
> /sys/fs/cgroup/systemd//service-manager.slice/cgroup.subtree_control:
> No such file or directory

Yeah, writing to cgroup.subtree_control to enable or disable
controllers for a hierarchy is v2-only; for cgroups v1, controllers
are attached to a hierarchy by passing their names as mount options.
And that creates a related issue: system-manager does the C++
equivalent of 'mount -t cgroup -o none,name=systemd cgroup
/sys/fs/cgroup/systemd', i.e. the hierarchy rooted in
/sys/fs/cgroup/systemd doesn't have cgroup controllers attached, so
subdirectories won't have any 'knobs' for set-control-group-knob(1) to
act on:

$ cat /proc/self/cgroup
1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service

$ ls 
/sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service
cgroup.clone_children
cgroup.procs
notify_on_release
tasks

If one mounts another cgroup hierarchy with attached controllers, for
example with 'mount -t cgroup -o cpu cgroup /sys/fs/cgroup/cpu', the
corresponding knobs won't be in the directory set-control-group-knob
expects to find them:

$ cat /proc/self/cgroup
2:cpu:/cgroup-in-cpu-hierarchy
1:name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service

$ ls /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy
cgroup.clone_children
cgroup.procs
cpu.shares
notify_on_release
tasks

$ cat /sys/fs/cgroup/cpu/cgroup-in-cpu-hierarchy/cpu.shares
1024

$ set-control-group-knob cpu.shares 2048
set-control-group-knob: FATAL:
/service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares:
No such file or directory

One could instead attach controllers to the hierarchy rooted in
/sys/fs/cgroup/systemd, for example by mounting it with 'mount -t
cgroup -o cpu,name=systemd cgroup /sys/fs/cgroup/systemd' (not with
system-manager as process 1), and things would appear to be OK:

$ ls 
/sys/fs/cgroup/systemd/service-manager.slice/ttylogin\@.service/ttylogin\@tty1.service
cgroup.clone_children
cgroup.procs
cpu.shares
notify_on_release
tasks

(i.e. there is now a 'cpu.shares' file)

But then set-control-group-knob (and also move-to-control-group I
believe) becomes a no-operation because it can't find the cgroups
hierarchy; function calls like read_my_control_group(self_cgroup,
"name=systemd", current) in source/set-control-group-knob.cpp and
source/move-to-control-group.cpp will return false because
/proc/self/cgroup doesn't have the expected format:

$ cat /proc/self/cgroup
1:cpu,name=systemd:/service-manager.slice/ttylogin@.service/ttylogin@tty1.service

(The text between the colons now also contains the cgroup controller
name, not just the 'name=systemd' part)

$ set-control-group-knob cpu.shares 2048
$ cat 
/sys/fs/cgroup/systemd/service-manager.slice/ttylogin@.service/ttylogin@tty1.service/cpu.shares
1024

$ set-control-group-knob non-existent-knob 2048

(No output, not even a 'No such file or directory' error).

G.

nosh: service-control --exit

[Guillermo]

Hello,

2016-08-06 14:30 GMT-03:00 Jonathan de Boyne Pollard:
>
> svc -x
> ==
>
> The -x option to service-control, a.k.a. svc, is no longer defunct. It does
> what unload-when-stopped does.

There is a minor difference: for some reason 'service-control --exit'
doesn't unload a service that is already in the 'stopped' state. It
will be unloaded if it is later started and then stopped. In contrast,
'system-control unload-when-stopped' unloads a stopped service
immediately (which IMO is the desirable effect).

Thanks,
G.

s6-rc: Managing small changes to the active services database

[Guillermo]

Hello,

Consider a fully s6-rc-managed machine. Such a machine would have an
'active' services database (the compiled database linked from s6-rc's
live state directory), and some place where service definitions would
be stored in source format. The active services DB would have been
initially created by running s6-rc-compile on all or part of these
definitions. I don't know what everyone else does, but the source
directory I give to s6-rc-compile is usually a temporary directory
with symbolic links to definitions stored somewhere else (in a sort of
services repository), that I delete afterwards.

After initial creation, with the possible exception of bundle
definitions, I imagine the active DB would be mostly static, and
expect changes to be generally small, like e.g. adding a couple of
services when there is a newly installed software package. Changes are
performed by running s6-rc-update on a new compiled DB, but
s6-rc-compile currently requires the full set of services in source
format to create one. So how would one manage this? Should one really
keep the source directories supplied to s6-rc-compile instead of
throwing them away, so they can be reused? Or construct a temporary
source directory from the services list returned by running s6-rc-db
on the live state directory, and then make the changes? Or...?

Also, depending on what method is used, there is the chance of missing
changes made in-place after the initial s6-rc-init invocation, like
using s6-rc-bundle on the live state directory to modify bundle
definitions (s6-rc-db's 'contents' subcommand could catch these), or
modifying longruns' env/ and data/ directories through the symlinks in
the scan directory (s6-rc-db cannot catch these).

Thoughts?
G.

Re: Adding capability control into the `run' script comparison page

[Guillermo]

2016-12-07 6:26 GMT-03:00 Jean Louis:
>
> On Wed, Dec 07, 2016 at 09:14:00AM +, Jonathan de Boyne Pollard wrote:
>> [...]
>> To anyone running the service manager and bundles from nosh version 1.28 or
>> later on Linux:  You are encouraged to look at your control group hierarchy,
>> with a tool like "systemd-cgls /", with the "cgroup" field of the ps
>> command, or by simply listing your /sys/fs/cgroup/ hierarchy.  You are in
>> for an interesting surprise.
> [...]
>
> Please be more detailed, I am interested, but due to not using
> systemd, I ahve nothing in /sys/fs/cgroup
>
> What is the interesting surprise, explained?

nosh 1.28 and later includes a move-to-control-group chainloading
utility [1], and its systemd unit file conversion tool inserts a
move-to-control-group invocation in the resulting bundle directory's
scripts.

I suppose the interesting suprise is that as consequence, when a
service definition gets 'imported' to nosh from a unit file (and this
covers pretty much everything in the nosh-bundles* binary packages),
the corresponding service gets placed in a cgroup of its own when
launched by nosh's service manager:

test$ cat my-test-svc.service

[Unit]
Description=My test service

[Service]
User=test
ExecStart=/home/test/my-test-svc-binary
RestartSec=1

test$ system-control convert-systemd-units --no-systemd-quirks
./my-test-svc.service
test$ ls -l my-test-svc/*

my-test-svc/after:
total 0
lrwxrwxrwx 1 test test 34 Dec  7 22:25 basic ->
/etc/service-bundles/targets/basic

my-test-svc/before:
total 0
lrwxrwxrwx 1 test test 37 Dec  7 22:25 shutdown ->
/etc/service-bundles/targets/shutdown

my-test-svc/conflicts:
total 0

my-test-svc/required-by:
total 0

my-test-svc/service:
total 16
-rwxr-xr-x 1 test test 105 Dec  7 22:25 restart
-rwxr-xr-x 1 test test 183 Dec  7 22:25 run
-rwxr-xr-x 1 test test  66 Dec  7 22:25 start
-rwxr-xr-x 1 test test  65 Dec  7 22:25 stop

my-test-svc/stopped-by:
total 0
lrwxrwxrwx 1 test test 37 Dec  7 22:25 shutdown ->
/etc/service-bundles/targets/shutdown

my-test-svc/wanted-by:
total 0

my-test-svc/wants:
total 0
lrwxrwxrwx 1 test test 34 Dec  7 22:25 basic ->
/etc/service-bundles/targets/basic

test$ system-control cat ./my-test-svc

start:#!/bin/nosh
start:#Start file generated from ./my-test-svc.service
start:true
stop:#!/bin/nosh
stop:#Stop file generated from ./my-test-svc.service
stop:true
run:#!/bin/nosh
run:#Run file generated from ./my-test-svc.service
run:#My test service
run:move-to-control-group my-test-svc.service
run:setuidgid test
run:/home/test/my-test-svc-binary
restart:#!/bin/sh
restart:#Restart file generated from ./my-test-svc.service
restart:sleep 1
restart:exec true # ignore script arguments

root# mkdir /sys/fs/cgroup/systemd
root# mount -t cgroup -o rw,nosuid,nodev,noexec,name=systemd systemd
/sys/fs/cgroup/systemd
root# system-control start ./my-test-svc

test$ service-status my-test-svc

my-test-svc:
 State   : running since 2016-12-07 22:35:37 -0300; 7m 48s ago
 Main PID: 1499
  Started: exit 0
 Config  : enabled

test$ ps -eo pid,ppid,euser,cgroup,args

  PID  PPID EUSERCGROUP  COMMAND
 [...]
 1446 1 root -   service-manager
 1499  1446 test 6:name=systemd:/my-test-svc /home/test/my-test-svc-binary

Process 'my-test-svc-binary' is in cgroup 'my-test-svc.service' and
its parent process (PID 1446) is a process supervisor, as expected.

test$ ls -l /sys/fs/cgroup/systemd

total 0
drwxr-xr-x 2 root root 0 Dec  7 22:13 basic.target
-rw-r--r-- 1 root root 0 Dec  7 22:06 cgroup.clone_children
-rw-r--r-- 1 root root 0 Dec  7 22:06 cgroup.procs
-r--r--r-- 1 root root 0 Dec  7 22:06 cgroup.sane_behavior
drwxr-xr-x 2 root root 0 Dec  7 22:13 local-fs-pre.target
drwxr-xr-x 2 root root 0 Dec  7 22:13 local-fs.target
drwxr-xr-x 2 root root 0 Dec  7 22:35 my-test-svc.service
-rw-r--r-- 1 root root 0 Dec  7 22:06 notify_on_release
-rw-r--r-- 1 root root 0 Dec  7 22:06 release_agent
drwxr-xr-x 2 root root 0 Dec  7 22:13 swapauto.target
drwxr-xr-x 2 root root 0 Dec  7 22:13 swaplate.target
drwxr-xr-x 2 root root 0 Dec  7 22:13 sysinit.target
-rw-r--r-- 1 root root 0 Dec  7 22:06 tasks

(/sys/fs/cgroup itself is a tmpfs on my machine)

G.

[1] http://jdebp.eu/Softwares/nosh/guide/move-to-control-group.html

Re: How to trap ctrl-alt-del?

[Guillermo]

2016-11-25 6:28 GMT-03:00 Colin Booth:
>
> On Nov 25, 2016 3:53 AM, "Casper Ti. Vector" wrote:
>>
>> On Fri, Nov 25, 2016 at 11:07:15AM +0300, Jean Louis wrote:
>>>
>>> How may I trap ctrl-alt-del,
>>
>> $ sysctl kernel.ctrl-alt-del=0
>
> This is a bit misleading since most (all?) default builds of linux already
> have kernel.ctrl-alt-del set to zero.

Acually, booting my own system with init=/bin/sh (i.e. without a
"proper" init) a couple of months ago I found the opposite to be true,
and IIUC this is also what happened to the OP. Anyway, if one wants to
trap CTRL+Alt+Del it probably *is* a good idea to explicitly set it
with 'sysctl kernel.ctrl-alt-del=0', or some equivalent of 'echo 0
>/proc/sys/kernel/ctrl-alt-del' after mounting /proc, instead of
relying on whatever happens to be the kernel's default.

2016-11-25 5:07 GMT-03:00 Jean Louis:
>
> While previously the ctrl-alt-del was trapped by SysV (or whatever),
> so that system runs "halt", `[...]

sysvinit does indeed turn CTRL+Alt+Del trapping on explicitly in the C code.

2016-11-26 9:10 GMT-03:00 Jean Louis:
>
> Now I wonder how to practically implement the -s option, should I just
> give it something like "sudo s6-poweroff"?
>
> On Fri, Nov 25, 2016 at 12:17:24PM +0300, Jean Louis wrote:
>> Now I found a solution
>> http://www.mail-archive.com/supervision%40list.skarnet.org/msg01038.html

You write a diverted SIGINT handler according to the s6-svscan
documentation, as mentioned earlier, that at some point performs an
's6-svscanctl -6' or 's6-svscanctl -rt' on the scan directory, to make
s6-svscan exec into its 'finish' script with a 'reboot' argument. The
actual rebooting would be done directly or indirectly in the 'finish'
script. What else exactly the diverted SIGINT handler needs to do
depends on your setup, which brings me to...

2016-11-25 5:07 GMT-03:00 Jean Louis:
> [...] now when I have switched to s6-rc an s6-tools, [...]

You say you switched to s6-rc, are you not already running s6-svscan
as process 1 in "divert signals mode" (-s)? Also as mentioned earlier,
there is the s6-linux-init package, and the model of operation of its
s6-linux-init-maker program relies on directly or indirectly
performing an 's6-rc change' from a diverted signal handler to cleanly
bring the services down [1]. Are you using a custom setup instead?

If you use the unmodified s6-linux-init-maker output, you write a
suitable stage2_finish script to bring s6-rc services down, and you
want CTRL+Alt+Del to mean "reboot", then you don't have to do anything
special besides turning the feature on (in the stage2 script or an
s6-rc oneshot); s6-linux-init-maker creates a diverted SIGINT handler
for you (needed for the s6-reboot program to work, now also in
s6-linux-init) that does what you want.

[1] Explained in detail here under the "Shutdown sequence" title:

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Guillermo]

2016-08-22 7:15 GMT-03:00 Laurent Bercot:
>
>  The next s6+friends version release will have major version bumps all
> around, so compatibility is moot anyway. If you really think it's worth it
> to swap SIGUSR1 and SIGUSR2, I'll do it.

It would be more aesthetically pleasing if s6-halt sent SIGUSR1,
s6-poweroff sent SIGUSR2, and s6-reboot sent SIGTERM, in the sense
that it would make a couple of init systems almost agree, but that's
it. At this point, reassigning the 'reboot' meaning to SIGTERM would
probably more useful than swapping SIGUSR1 and SIGUSR2, because it
frees SIGINT, an therefore CTRL + Alt + Del, to do whatever the
administrator or distribution pleases, like in the
/etc/s6-init/ctrlaltdel example I gave.

But from a user's point of view, as long as s6-halt, s6-poweroff and
s6-reboot "just work" and do what they say they do, everything is OK.
Which means that 'out of the box' s6-linux-utils programs have to
agree with 'out of the box' s6-linux-init handlers, and this happens
already. Also, the way s6-svscan implements signal diversion is
flexible, so one can rearrange or modify s6-linux-init's handlers to
align with a different convention than s6-linux-utils' current one.

So, in conclusion: alignment with BusyBox init's convention is nicer,
but if you feel you'd rather use the time for something else, or if
changing the convention would break too many things, then I'd say
don't bother.

> I can also add SIGWINCH support to s6-svscan, but only when it's diverted,
> because there's no possible portable default semantics.

This would be nice to have, with the same treatment SIGUSR1 and
SIGUSR2 currently have: completely ignore them with -S, divert them
with -s. Last time I checked with a 3.14-series kernel, loadkeys(1)
and a suitable keymap file, the 'keyboard request' still worked (it is
usually mapped to Alt + Up arrow). And besides the init systems I
mentioned, systemd supports it too. So yeah.

The only additional requirement to use it is a Linux-specific
'ioctl(fd, KDSIGACCEPT, SIGWINCH)' call to turn 'keyboard request' on,
because last time I experimented, I found it to be off by default when
the kernel starts. s6-svscan can't do the ioctl itself without losing
portability, but a separate chainloading program in stage1 can.

Thanks,
G.

Re: s6-linux-init: SIGUSR1 and SIGUSR2

[Guillermo]

2016-08-21 6:15 GMT-03:00 Laurent Bercot:
>
> On 21/08/2016 06:18, Casper Ti. Vector wrote:
>>
>> It seems that the exchanging of SIGUSR1 and SIGUSR2 [1] in s6-linux-init
>> did not happen.  Is it just forgotten, or ...?
>
>  Well, by the point I remembered to make the change, I already had
> systems depending on the old behaviour :/

Heh. At the time this was brought up on the skaware ML, s6-rc had been
released a month before, s6-svscan had recently gained the signal
diversion feature (-s option), and s6-linux-init-maker (from
s6-linux-init), the ability to generate diverted signal handlers and
plug in a stage2_finish script, so that s6-rc could be added to the
init system. But what no skarnet.org packages provided at the time was
programs that sent signals to process 1. With the SIGUSR1/2 swap,
BusyBox's halt, poweroff and reboot applets would have been able do
the job. But s6-halt, s6-poweroff and s6-reboot (from s6-linux-utils
version >= 2.1.0.0) can now send signals to process 1, so the issue
was resolved, although in a different way.

>  It's purely a convention anyway, and busybox init, sinit and sysvinit all
> disagree - so I'm afraid there can't be a generic "shutdown" client;
> every init system must come with its own "shutdown" program, that honors
> its own convention.

Yeah, it seems it has come to that :) But the funny thing is a few of
the init systems for [GNU/]Linux are, or can be made to be, *almost*
(to different degrees) compatible with this signal set:

a) SIGTERM for reboot
b) SIGUSR1 for halt
c) SIGUSR2 for poweroff
d) SIGINT for a programmable CTRL + ALT + Del action
e) SIGWINCH for a programmable 'keyboard request' action

sysvinit a.k.a van Smoorenburg init supports d) and e) via lines with
the 'kbrequest' and 'ctrlaltdel' actions in /etc/inittab, but not a)
to c). That is handled instead by communication over the /dev/initctl
FIFO.

BusyBox init supports almost all, even d) via lines with the
'ctrlaltdel' action in /etc/inittab (if it was built with
FEATURE_USE_INITTAB enabled), but not e).

nosh's system-manager supports e) via the 'kbrequest' target. But for
compatibility reasons, supports d) on [GNU/]Linux via the
'secure-attention-key' target, but not on the BSDs, where SIGINT means
'halt'. Supports a) and b) on the BSDs, but not c), because SIGTERM
means 'enter rescue mode'. And doesn't support a) to c) on
[GNU/]Linux, because it follows the systemd signal convention (signals
above SIGRTMIN) there instead.

It should be noted that one can make s6 + s6-rc support a) to d) with
little effort by running s6-linux-init-maker, and then adapting the
diverted signal handlers instead of using them as-is:

* swapping $basedir/run-image/.s6-svscan/SIGUSR1 and
$basedir/run-image/.s6-svscanSIGUSR2
* moving $basedir/run-image/.s6-svscan/SIGINT to
$basedir/run-image/.s6-svscan/SIGTERM
* and writing a custom $basedir/run-image/.s6-svscan/SIGINT. E.g. one
that chains to, say, /etc/s6-init/ctrlaltdel if that file exists and
is executable, and returns 0 if not.

What can't be implemented is e), because s6-svscan can't currently
divert SIGWINCH. And even then, one would also need a (Linux-specific)
chainloading tool that does the KDSIGACCEPT ioctl for SIGWINCH on
/dev/console to enable the feature, so it could be insterted in the
stage1 script before it redirects stdin and chains to s6-svscan. But
that tool can be written without much effort either, I think.

G.

Re: nosh version 1.28

[Guillermo]

Hi,

2016-08-06 14:30 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.28 .

Could the plain 'setlock' invocation in script source/default.html.do
be changed to './exec setlock', as in scripts source/default.1.do and
source/default.8.do, please? Otherwise we have the chicken-and-egg
situation we had with nosh-1.19:



> OpenBSD
> ===
>
> [...]
> There are an awful lot of limitations to OpenBSD, [...]

How funny it is that this summary and the WWW page echo the sentiments
in skarnet.org packages' source files comments and commit messages :D

Thanks,
G.

Re: How to make svlogd send logs via UDP

[Guillermo]

2016-02-06 2:25 GMT-03:00 Nicolas de Bari Embriz Garcia Rojas:
>
> also wondering if it is posible to use a domain name instead of an IP

If you mean in the u or U lines of the config file, then no, they only
accept an IPv4 address.

G.

Re: nosh version 1.23

[Guillermo]

2015-12-17 10:50 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.23 .

Hi,

It seems that the 'unload-when-stopped' and 'version' subcommands of
system-control are not mentioned in the documentation. They are listed
in the output of 'system-control --help', though. I discovered the
existence of the former because it is used in some of the scripts in
the package/debian/ and package/bsd/ directories of the source
package.

Also, after building the target bundle directories
(/etc/service-bundles/targets/*) from source, the 'virtualbox-host'
one contains a 'kmod@vboxpci' dangling symlink in its wants/
subdirectory that doesn't look right to me. So I looked at the
source/targets/virtualbox-host.target file from which the bundle is
created, and, IMHO, there are some issues with it.

First, it has multiple 'Wants=' lines naming a few kmod@vbox*
services, not just kmod@vboxpci. But 'system-control
convert-systemd-units' appears to only take into account the last one.

And second, IIUC, since the filename ends in '.target',
convert-systemd-units assumes unsuffixed bundle names in the 'Wants='
lines refer to targets, and the resulting symlink is constructed as
'../../kmod@vboxpci'. Which would point to a nonexistent
/etc/service-bundles/targets/kmod@vboxpci bundle directory.

But on a more conceptual level, I don't really understand why these
'Wants=' lines are even there. The relevant kmod@vbox* service bundle
directories that come with the nosh package already name the
virtualbox-host target in their wanted-by/ subdirectories. So if one
actually needs them, then 'system-control enable' or 'system-control
preset' would take care of populating the wants/ subdirectory of
virtualbox-host, wouldn't they?

Thanks,
G.

Re: nosh: service-dt-scanner gets repeatedly killed by SIGABRT

[Guillermo]

2015-07-06 22:01 GMT-03:00 Guillermo:
>
> I wanted to try out nosh daemontools-style, i.e. using
> service-dt-scanner and launching service-manager "by other means"
> [...]
> However, under certain circumstances service-dt-scanner receives a
> SIGABRT signal and dies:

2015-07-12 9:45 GMT-03:00 Jonathan de Boyne Pollard:
>
> Remember that I said that my immediate suspicion is a (fourth) libkqueue
> bug?  It's a fourth libkqueue bug.
> [...]
> As the inotify(7) manual page says, if an event is larger than the buffer
> size given to read(), it fails with EINVAL.  And events can be larger than
> sizeof(struct notify_event).  libkqueue doesn't deal with this failure
> properly, leading to a call to abort():

... and using nosh version 1.22, the one that no longer depends on
libkqueue, service-dt-scanner doesn't die anymore. Also, modifying the
scan directory (e.g. placing a symbolic link to a bundle or service
directory with daemontools layout, or directly copying it) correctly
triggers a scan, which previously didn't work very well for me either.

http://www.mail-archive.com/supervision%40list.skarnet.org/msg01043.html

So problem solved. Thank you, this is a major improvement.
G.

Re: [ale] systemd talk from July has slide deck online now

[Guillermo]

2015-09-09 2:04 GMT-03:00 Steve Litt:
>
> If I want to use s6 as my init, what do I do, just put into my Grub
> kernel line init=/usr/bin/s6 or whatever the s6 executable is?

If you want to use the s6-linux-init package and minimum
customization, in addition to s6 and s6-linux-init, you'll need to
download and build two more skarnet.org packages, s6-linux-utils and
s6-portable-utils, and then you can follow the quickstart guide:

http://www.skarnet.org/software/s6-linux-init/quickstart.html

The described procedure however replaces /sbin/init, after backing it
up, with the saved output of s6-linux-init-maker, i.e. /tmp/init,
which is what the s6-linux-init documentation calls "the stage1
script". If you want to go the "new GRUB menu entry" route, it would
change to something like:

(As root)
rm -rf /tmp/s6-linux-init /tmp/s6-stage1-init
s6-linux-init-maker [options] /tmp/s6-linux-init > /tmp/s6-stage1-init
chmod 0700 /tmp/s6-stage1-init
mv /tmp/s6-linux-init /etc
mv /tmp/s6-stage1-init /sbin

The new GRUB menu entry can then pass an 'init=/sbin/s6-stage1-init'
option to the kernel. And you halt, reboot or poweroff the machine
with 's6-svscanctl -st /run/service', 's6-svscanctl -rt /run/service'
or 's6-svscanctl -pt /run/service', respectively. The
s6-linux-init-maker options you may additionally need or want are -d,
-u, -p and -e.

Note that you also need to write two scripts, /etc/rc.init and
/etc/rc.shutdown. These are what the s6-linux-init documentation calls
"the stage2 script" and "the stage3 script". But they serve the same
purpose as the ones in your Suckless Init document, so you already
know what goes in there. There are some notable differences, though:

 * The scan directory is /run/service, not /service, so it will be a
directory in a tmpfs, that is created and populated at boot time with
a (very small) initial set of services by the stage1 script. You then
have to copy or make symbolic links to the service directories you
want, which you would have in a non-volatile "service repository",
like /etc/sv, /var/service, /var/svc.d as OpenRC likes it, etc. and
then do an 's6-svscanctl -a /run/service'. All these actions can be
programmed inside /etc/rc.init.

 * /etc/rc.init will start executing when s6-svscan is already running
as process 1, so you don't need to call any svscanboot-like command at
the end of the script. You just let it finish and return when it's
done. It will be running as a child of s6-svscan and get reaped when
it returns.

 * /etc/rc.shutdown will be called with a single argument: 'halt',
'poweroff' or 'reboot', depending on the requested shutdown mode. And
will run as process 1 when the machine is shutting down, so if it
aborts or exits before executing the final halt, reboot or poweroff,
you'll get a kernel panic. Write it carefully.

 * Inside /etc/rc.shutdown, you can use s6-halt, s6-poweroff and
s6-reboot in place of sysvinit's counterparts. These programs come
with the s6-linux-utils package. And you can use 's6-nuke -t' and
's6-nuke -k' in place of 'killall5 -15' and 'killall5 -9',
respectively. The s6-nuke program comes with the s6-portable-utils
package. This will remove all dependencies on sysvinit-like binaries.
In particular, the ones that expect to talk to process 1 through
/dev/initctl won't even work.

Cheers,
G.

Re: nosh version 1.19

[Guillermo]

2015-08-22 15:04 GMT-03:00 Jonathan de Boyne Pollard:
>
> nosh is now up to version 1.19

Hi, I had some issues with the source package I thought I should mention:

* source/common-manager.cpp wouldn't compile on my Gentoo system,
because this new version calls setrlimit(), and makes use of struct
rlimit and the RLIMIT_NOFILE macro, without directly or indirectly
including . I had to add that manually to make it
compile.

* I had a chicken-and-egg situation with the source/default.1.do and
source/default.8.do scripts: they make use of setlock, which wouldn't
be available without a previous nosh installation. I had to change it
to './exec setlock', and add 'exec' to the redo-ifchange invocation,
to overcome this.

Thanks,
G.

Re: s6: compatibility with make3.82

[Guillermo]

2015-08-08 15:49 GMT-03:00 Laurent Bercot:

 Not using vpath would result in not checking
 external libraries (so, fo instance, failing to rebuild if libskarnet.a
 changes)

And I don't know why you would want to do that. Software packages
usually don't bother; external libraries are at most checked to exist
and work during configuration phase, and that's it. This would only be
useful, I suppose, if you keep, say, execline's build directory intact
until the next upgrade, instead of just erasing it, and want to save
some build time in case you upgrade skalibs and want the same version
of execline to link with the new libskarnet?

But it's not a big deal anyway, I only said I didn't like it :)

 [1] https://bugs.gentoo.org/show_bug.cgi?id=541092
  Can you please translate that bug and/or give a concrete example ?
 I can't speak Gentooese, so I don't understand either the bug-report
 or the patch. ^^'

Hahaha, sure. Take for example execline, and assume you want to
*upgrade* it to a more recent version. Or that for some reason you
want to reinstall (new skalibs version, etc.). That is, you *already
have* a libexecline.so and/or libexecline.a, and the newly built ones
are going to be installed in the same directory as the older ones,
replacing them. That's what the person who made the bug report was
doing (indirectly through Gentoo's package manager).

What happens then? There are makefile rules containing
'libexecline.so' or 'libexecline.a' prerequisites, depending on what
configure options were used. There are vpath directives specifiying
library directories, so that '-lskarnet' prerequisites work. And there
is the possibility that the directories in which libexecline.{a,so}
are going to be installed ('libdir' and/or 'dynlibdir'), might be
shared with libskarnet.{a,so}. For example, because the user wants to
dump all skarnet.org package dynamic libraries in, say, /lib or
/lib/skarnet. In the case of that bug report, libskarnet.so and
libexecline.so were both installed in /lib64, so let's take that to
continue the exposition.

The result is that make gets confused about the libexecline.so
prerequisite, because there is a /lib64/libexecline.so already, the
old library about to be replaced, that is found as a result of vpath
search. And it sees two rules: the rule for the plain libexecline.so
target in package/deps.mak, that has prerequisites but no recipe, and
a pattern rule '$(DESTDIR)$(dynlibdir)/lib%.so:' with a recipe in the
main makefile, that can match a /lib64/libexecline.so target and a
plain libexecline.so prerequisite. The prerequisite gets discarded
with a 'circular dependency dropped' warning, because make thinks it
means the /lib64/libskarnet.so found via vpath search:

make: Dipendenza circolare /lib64/libexecline.so -
/lib64/libexecline.so scartata.

(in Italian because of the reporter's LANG=it setting)

So that leaves it a rule with no prerequisites, that gets combined (in
a kinda hilarious way) with the other rule with no recipe. And make
ends up deciding, after expansion of '$' to
'src/libexecline/el_execsequence.lo' (the first prerequisite in the
rule for plain libexecline.so), that the recipe to build the library
is './tools/install.sh -D -m 755 src/libexecline/el_execsequence.lo
/lib64/libexecline.so.2.0.2.1  [...]'. And boom. That would
overwrite the existing library with a newly built object file, and for
the next executable that needs libexecline.so, that one will be picked
up because of vpath, and make will ultimately fail with a linker
error.

This will happen with static libraries as well, provided the setup is
similar, and will happen for s6 with libs6.{a|so}. The workaround
proposed in that report? Building the package using 'make
DESTDIR=dummy-directory' instead of a plain 'make'. 'dummy-directory'
doesn't even have to exist, its only purpose is that target
$(DESTDIR)$(dynlibdir)/lib%.so can no longer match
/lib64/libexecline.so and confuse make, so the two makefile rules do
not get combined, and libexecline.so gets built using the 'lib%.so:'
rule. And because the new libexecline.so exists now in the build
directory, the prerequisite search algorithm will prefer it over the
old library found via the vpath directive, so executables will also be
correctly built. Of course, the 'make install' step should use a
proper DESTDIR, if any.

In the specific case of that report, because Gentoo is a source-based
distribution and its package manager builds sotfware in a temporary
directory, and sets up a sandbox to do it, when make tries to
overwrite the existing library in the /lib64 directory, what happens
is that a sandbox violation is triggered because /lib64 is not allowed
to be written, and everything is aborted. What the patch talked about
does is modify the Gentoo ebuild, i.e. Gentoo's recipe to build
the package from source, so it uses the DESDTIR trick for the compile
phase.

Cheers!
G.

Re: s6: compatibility with make3.82

[Guillermo]

Hello,

2015-08-07 20:29 GMT-03:00 Buck Evan:

 s6-user@696f14e9c9bd:~/scratch$ /opt/make/make
 make: *** No rule to make target '-lc', needed by 'all'.  Stop.

 s6-user@696f14e9c9bd:~/scratch$ /opt/make/make --version
 GNU Make 4.1
 Built for x86_64-unknown-linux-gnu

That's not strange. This is how -l-style prerequisites work:

http://www.gnu.org/software/make/manual/html_node/Libraries_002fSearch.html

(I believe the documentation is partially wrong, it should say
'libdir' instead of 'prefix/lib', with 'libdir' being the value
specified for the --libdir option of the configure script. But if it
is not specified, it does default to 'prefix/lib')

Your distribution has libc.so in /usr/lib/x86_64-linux-gnu; that's not
/lib, not /usr/lib, and probably not $prefix/lib either, for whatever
--prefix you specified to the configure script. So libc.so is not
found, and because there is no rule in the makefile for building it,
make fails. Saying '/opt/make/make VPATH=/usr/lib/x86_64-linux-gnu'
would probably make the example work.

 s6-user@696f14e9c9bd:~/scratch$ make
 echo /usr/lib/x86_64-linux-gnu/libc.so
 /usr/lib/x86_64-linux-gnu/libc.so

 s6-user@696f14e9c9bd:~/scratch$ make --version
 GNU Make 3.81

This is actually the surprising result for me :) But then again, if
this is the Debian-provided make, who knows what the distribution's
developers do to build and package it.

Anyway, the skarnet.org package's configure scripts generate makefile
fragments with appropriate explicit vpath directives, so all libraries
specified via -l-style prerequisites would be found. Therefore, things
like the one in this example shouldn't happen if correct --with-lib or
--with-dynlib options are specified, should they be needed for a
particular setup.

I do not like the skarnet.org package build system's use of vpath
magic instead of relying on the compiler's library search algorithm,
and I will confess I have occasionally patched it to remove the vpath
stuff. But that being said, the build system should normally work
(well, mostly [1]). And I agree with what was said about treating GNU
make version = 4.0 as just another dependency, building it from
source using ./configure --prefix=some-throwaway-temporary-dir, and
then adding some-throwaway-temporary-dir/bin to PATH to build skalibs,
execline and finally s6, being really the fastest way to get s6
installed on an OS that does not have a sufficiently recent version of
GNU make.

Cheers!
G.

P.S.: The last three messages from this thread for some reason do not
show up in www.mail-archive.com. They do in skarnet.org's local
archive.

[1] https://bugs.gentoo.org/show_bug.cgi?id=541092
That's the only real bug I believe the skarnet.org build system has so
far, i.e. make's prerequisite search algorithm getting confused if
libraries with the same name as the ones about to be installed are
already present in the target directories. But that report also
presents a simple and clever (but ugly) workaround that doesn't
involve patching the build system.

Re: supervision-scripts 2015-06

[Guillermo]

2015-07-08 22:07 GMT-03:00 Avery Payne:

 + A small comparison table has been added to the wiki, showing 6 different
 frameworks and their various related concepts.  It is incomplete but
 somewhat usable, and contains various links to sites, downloads, etc.
 Because there is still a lot of missing information, any additional hints,
 comments, or links sent to me are gladly accepted.

All right. According to my current understanding:

* License. nosh is ISC; the COPYING file from the source tarball
further says it may be considered copyright licensed under the terms
of any of the ISC license, the simplified (2 clause) BSD license, the
FreeBSD license or the MIT Expat license.

* Compatibility. For s6, I believe it was mentioned somewhere that it
is tested at least on FreeBSD, OpenBSD and Solaris. It is also in the
FreeBSD Ports Collection, and runit is too. On the other hand, the
execline scripts produced by s6-linux-init-maker (from the
s6-linux-init package) that help getting s6-svscan to run as process 1
are Linux-specific.

* Supports slashpackage install. Possible for nosh, using the source package.

* Comes with init. The entry for s6 would probably be better stated as
s6-linux-init-maker's output. This output is an execline script, the
stage 1 init, that, when saved to a file, put on a suitable place in
the filesystem, and made executable, can be used as the argument of
the kernel's init parameter and run as process 1. After performing
some initialization tasks it replaces itself with s6-svscan, and, if
s6-linux-init-maker was called with default options, use /run/service
as its scan directory. One still needs to write a stage 2 init and
pass it to s6-linux-init-maker with the -2 option (or, without it, the
stage 2 init has to be /etc/rc.init), the same way as one needs to
write an /etc/runit/1 file for runit.

* The row containing readproctitle. It could be renamed to
supervision tree log handling or something like that, and may fit
better in section Logging. The entries for s6 and nosh could be
catch-all logger (s6-svscan-log), again from the s6-linux-init
package, and catch-all logger (cyclog), respectively. The catch-all
logger being a supervised long-lived process that receives and logs
(to a log directory) all output from the supervision tree, including
the one from processes that do not have a dedicated logger.

For s6, s6-linux-init-maker with default options produces a directory
that must be copied to /etc/s6-linux-init/run-image, and contains a
service directory named s6-svscan-log for a catch-all logger. When
the machine boots, it will be copied to s6-svscan's scan directory by
the stage 1 init. This catch-all logger is an s6-log process that logs
to directory /run/uncaught-logs.

For nosh, if system-manager runs as process 1, it will automatically
create and supervise a cyclog process with hardcoded options, that
logs to directory /run/system-manager/log, and pretty much acts as a
catch-all logger, too.

For runit, you did not mention the program that has the self-renaming
behaviour, i.e. the one you have to look for in ps' output to get the
logs. It is runsvdir.

* Supervisor Programs. For nosh, the program similar to svscan would
be service-dt-scanner, in the sense that it runs on a scan directory.
Footnote 2 would apply (only to service-dt-scanner), since it can also
be called as svscan. The program similar to supervise would be
service-manager, in the sense that supervised processes run as its
children, and it will restart them if they exit or crash (and if the
restart file in their respective service directory says so).

But things don't work in nosh as they do in the other software
packages. In particular, when system-manager runs as process 1, there
is a single service-manager process (supervised by system-manager),
not one per supervised process, there is no scan directory, and
service-dt-scanner doesn't run. System state changes are carried out
by the system-control program, called either by the system's
administrator, or in some cases automatically by system-manager.
system-control runs as a short-lived process that exits when it is
done.

* Supports using a supervisor-as-init. For the reasons stated in the
bullet above, for nosh it would be a No or N/A.

* Force a service to stay in the same process group. I haven't used
daemontools[-encore] or runit, but looking at their source code,
pgrphack and chpst -P use the setsid() system call, so this row should
rather be create a new session and make the service the session
leader, and the entries for s6 and nosh would be s6-setsid and
setsid, respectively.

* TAI64 Tools. nosh also provides a tai64n and a tai64nlocal program,
with the same names as their daemontools counterparts.

Except for setpgrp, the program names with question marks in the
column for nosh are correct. Footnote 2 also applies to the ones in
section Service Control  Communication, they can be called using
the daemontools name.

Cheers!
G.

Re: nosh: service-dt-scanner gets repeatedly killed by SIGABRT

[Guillermo]

2015-07-08 5:30 GMT-03:00 Jonathan de Boyne Pollard:

 If there's no error output, crank up strace and see what the last few system
 calls are.  It's probably worthwhile doing that anyway, in fact.

Here are the last system calls shown by an strace of
service-dt-scanner before the SIGABRT, with some relevant previous
lines. The specific test was using ls on the service's bundle
directory, which was a direct subdirectory of the scan directory, and
had daemontools-compatible layout.

At one point, this happens:

epoll_create(1) = 4
openat(AT_FDCWD, scandir,
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
gettid()= 1328
fstat64(6, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

Then there is a readlink() call on /proc/1328/fd/6 (scandir
happened to be a symbolic link) and then:

inotify_init()  = 7
inotify_add_watch(7, /path-to/test/scandir, IN_MODIFY|IN_ATTRIB|IN_CLOSE) = 1
epoll_ctl(4, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=159460944, u64=159460944}}) = 0

/path-to/test/scandir represents here what was the complete path to
the scan directory.

And now the complete final lines:

fstatat64(11, down, 0xbfe6af30, 0)= -1 ENOENT (No such file or directory)
rt_sigaction(SIGALRM, {0x806e971, [], 0}, {SIG_DFL, [], 0}, 8) = 0
alarm(5)= 0
openat(12, ok, O_WRONLY|O_NOCTTY|O_CLOEXEC) = 13
close(13)   = 0
alarm(0)= 5
rt_sigaction(SIGALRM, {SIG_DFL, [], 0}, NULL, 8) = 0
openat(12, control, O_WRONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = 13
write(13, u, 1)   = 1
close(13)   = 0
close(12)   = 0
close(11)   = 0
close(10)   = 0
getdents(9, /* 0 entries */, 32768) = 0
close(9)= 0

(File descriptors were 9 = the scan directory, after a dup(6), 10 =
bundle directory of the service, 11 was the result of a dup(10), 12 =
supervise/ subdirectory of the service's bundle directory)

epoll_wait(4, {{EPOLLIN, {u32=159460944, u64=159460944}}}, 1, -1) = 1
gettid()= 1328
read(7, \1\0\0\0\20\0\0@\0\0\0\0\0\0\0\0, 16) = 16
write(2, service-dt-scanner: DEBUG: event..., 59) = 59

(That was an ls command on the scan directory, that produced this
output: service-dt-scanner: DEBUG: event filter 0 ident 6 fflags 6)

epoll_wait(4, {{EPOLLIN, {u32=159460944, u64=159460944}}}, 1, -1) = 1
gettid()= 1328
read(7, 0xbfe6b0cc, 16) = -1 EINVAL (Invalid argument)
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(1328, 1328, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=1328, si_uid=1000} ---
+++ killed by SIGABRT +++

I did the strace a couple of different times, and all outputs ended
like this, a read() call on the file descriptor returned by the
inotify_init() that produces an EINVAL error, followed
rt_sigprocmask() with a SIG_UNBLOCK argument, and the tgkill() that
sends the SIGABRT.

Thanks,
G.

Re: What interrupt does Ctrl+Alt+Delete send PID1?

[Guillermo]

 2015-06-12 9:44 GMT-03:00 Steve Litt:
 On Fri, 12 Jun 2015 11:31:44 +0200 Laurent Bercot wrote:

   Well, your host system will definitely catch the 3 finger salute; it
 won't be sent as is to your guest system. Is there a way for the VM to
 send an emulated ctrl-alt-del press to the guest ?

 Thanks Laurent,

 It looks like once I fully document my VM setup, I'll need to do the
 thing on bare metal.

Did you use the right key combination? You send an emulated CTRL + Alt
+ Del to the guest OS on VirtualBox with HOST Key + Del. HOST Key is
the right CTRL key by default, but you can change that via VirtualBox
configuration. In other words, if you don't change the HOST key
mapping, the emulated CTRL + Alt + Del is right CTRL + Del. A real
CTRL + Alt + Del will indeed go to the host OS.

Cheers,
G.

nosh on GNU/Linux: missing sys/event.h

[Guillermo]

Hello,

I tried to build nosh 1.16 from source code [1]. But some programs
fail to compile, complaining about a missing header, sys/event.h.
Which is true: there's no event.h file on /usr/include/sys, or
anywhere else on my system. Since nosh is supposed to build and run at
least on Debian 7, there must be some software package that provides
it for GNU/Linux, which nosh's webpage doesn't seem to mention. After
some Internet search, and noticing the small reference to the kqueue
mechanism on nosh's webpage, I ask: would the software package needed
to build nosh on GNU/Linux be libkqueue [2]?

Also, the redo thingy nosh wants to be built with seems to get stuck
in an loop, endlessly trying to compile those programs and failing. I
ended up killing the package/compile script with a CTRL+C.

Thanks,
G.

[1] 
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh/nosh-1.16.tar.bz2
- no, I don't use Debian, so the binary packages are not an option :)

[2] https://github.com/mheily/libkqueue