Re: runit patches to fix compiler warnings on RHEL 7

[Ben Franksen]

Am 27.11.19 um 21:33 schrieb J. Lewis Muir:
> On 11/25, J. Lewis Muir wrote:
>> Is runit hosted in a public source code repo?  If so, where?
>>
>> Are patches to fix runit compiler warnings on RHEL 7 welcome?
> 
> I have patches now.  Is there a public source code repo I can contribute
> against?  Or would it be helpful to just send the patches to the list?

Hi Lewis

it's cool to see you are interested in runit. May I ask whether you are
using it for controls / EPICS?

AFAIK there is no public repository for runit. You may want to ping
Gerrit Pape personally to get his attention. His last message to the
list is from march this year where he said he was "looking forward to do
a maintenance release of runit eventually and [...] collecting patches".

Cheers
Ben


pEpkey.asc
Description: application/pgp-keys

Re: runit patches to fix compiler warnings on RHEL 7

[Benjamin Franksen]

Am 02.12.19 um 22:58 schrieb Laurent Bercot:
>> I see something called sdnotify-wrapper, so maybe I should have a look
>> at that?  (It was mentioned to me off-list.)
> 
> sdnotify-wrapper will only be useful if your daemon is using the
> NOTIFY_SOCKET mechanism (aka sd_notify()) to tell systemd when it is
> ready. If it's the case, then yes, you can use sdnotify-wrapper in your
> s6 run script and it should automatically do the right thing.

Hi,

I was the one who told Lewis about sdnotify-wrapper and it seems I got
it completely wrong: I had thought it was a wrapper for daemons that use
the s6 notification mechanism to make them compatible with the systemd
convention. Your description above suggests it does the exact opposite.

Cheers
Ben

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

 I hope you find this comment useful.


 Yes, it was a very useful UX return, thank you.

 I think I'm going to work on an early version of s6-frontend, which
will only provide daemontools-style and/or runit-style command emulation
(depending on build-time options), and maybe a preliminary version of
the "s6" generic command as well. That way, at least the need for short
commands will be met, and the daemontools/runit muscle memory can be
actually leveraged for s6.

--
 Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

The browser is vastly superior for learning all about
unfamiliar or moderately familiar software, but for the quick lookup of
something you primarily know about, there's no substitute for a quick
"man execlineb".


 https://lmgtfy.com/?q=execlineb=1

--
 Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 12/04, Laurent Bercot wrote:
> > What about mandoc?
> 
> The colour of this bikeshed is not up for debate.
> 
> If you want man pages for skaware, provide me with:
> 1. a reasonable source format (e.g. not roff, so mandoc is right out)
> 2. a tool that can be built using *only* a C compiler (so as to keep
> bootstrapping skaware easy), that converts the source format into man
> pages *and* into HTML
> 3. the actual contents of the man pages you want, in that source format.
> 
> (https://git.sr.ht/~sircmpwn/scdoc fits 1. and 2., but its author wasn't
> motivated enough to do 3.)
 
Interesting, I hadn't heard of scdoc before.  I don't see where it says
it can convert the source format into HTML, though.  Did I miss that?

> Until then, any further discussion of documentation formats is pure
> noise, I've heard it all before - several times - and it has the potential
> to piss me off VERY quickly.

Certainly don't want to cause trouble, and not intending to bikeshed,
but I searched for "halibut" in the archive for this list as well as the
skaware list and did not find that it had been mentioned, so I'll just
mention that another system I've used in the past is Halibut which is
lightweight and written in ANSI C:

  https://www.chiark.greenend.org.uk/~sgtatham/halibut/

It can generate ASCII, HTML, PDF, PostScript, man, and info.  So, I
think it would satisfy #1 and #2, but certainly not #3.  Still, if
someone wanted to do the work to provide #3 at some point, then Halibut
may be a reasonable tool to consider.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

[Steve Litt]

On Wed, 4 Dec 2019 10:40:14 -0600
"J. Lewis Muir"  wrote:

> On 12/04, Jonathan de Boyne Pollard wrote:
> > Jan Braun:
> >   
> > > 2) runit has manpages. s6 has HTML. :(
> > >   
> > Daniel J. Bernstein had something to say on that subject, two
> > decades ago. See the "Notes" section of
> > http://cr.yp.to/slashdoc.html .
> > 
> > I generate both manual pages and HTML from a common DocBook XML
> > master in the nosh toolset.  And the DocBook XML is itself readable
> > directly with a WWW browser.
> > http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml
> > is a copy of one such DocBook XML master, for example.  It's on the
> > WWW, and the packages also install it locally, for off-line
> > reading.  
> 
> I still like having man pages.  It's often just easier to type "man
> " than to find the local (or remote) HTML document and open it
> in a web browser.

I never thought about man pages until a few days ago I did some
experiments with execline and had a quick question about syntax. I did
man execlineb and of course got "no entry". So I fired up a browser,
did a locate command, and put a path in my browser.

The browser is vastly superior for learning all about
unfamiliar or moderately familiar software, but for the quick lookup of
something you primarily know about, there's no substitute for a quick
"man execlineb".
 
SteveT

Steve Litt 
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

What about mandoc?


The colour of this bikeshed is not up for debate.

If you want man pages for skaware, provide me with:
1. a reasonable source format (e.g. not roff, so mandoc is right out)
2. a tool that can be built using *only* a C compiler (so as to keep
bootstrapping skaware easy), that converts the source format into man
pages *and* into HTML
3. the actual contents of the man pages you want, in that source format.

(https://git.sr.ht/~sircmpwn/scdoc fits 1. and 2., but its author wasn't
motivated enough to do 3.)

Until then, any further discussion of documentation formats is pure
noise, I've heard it all before - several times - and it has the 
potential

to piss me off VERY quickly.

--
Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 12/04, Jonathan de Boyne Pollard wrote:
> Jan Braun:
> 
> > 2) runit has manpages. s6 has HTML. :(
> > 
> Daniel J. Bernstein had something to say on that subject, two decades ago.
> See the "Notes" section of http://cr.yp.to/slashdoc.html .
> 
> I generate both manual pages and HTML from a common DocBook XML master in
> the nosh toolset.  And the DocBook XML is itself readable directly with a
> WWW browser.
> http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml is a
> copy of one such DocBook XML master, for example.  It's on the WWW, and the
> packages also install it locally, for off-line reading.

I still like having man pages.  It's often just easier to type "man
" than to find the local (or remote) HTML document and open it in
a web browser.

However, I agree that it's very nice to have HTML as well.  So, I like
to have both!  It seems good to generate them from a single source
format.  I would like DocBook except that the toolchain seems *so*
heavy.  And if you want to generate PDFs, it's even heavier.

What about mandoc?

  http://mandoc.bsd.lv/

It seems pretty lightweight, and from an mdoc source, it can generate
ASCII, HTML, man, PDF, and PostScript.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

[Jonathan de Boyne Pollard]

Jan Braun:


2) runit has manpages. s6 has HTML. :(

Daniel J. Bernstein had something to say on that subject, two decades 
ago.  See the "Notes" section of http://cr.yp.to/slashdoc.html .


I generate both manual pages and HTML from a common DocBook XML master 
in the nosh toolset.  And the DocBook XML is itself readable directly 
with a WWW browser. 
http://jdebp.uk./Softwares/nosh/guide/commands/setuidgid-fromenv.xml is 
a copy of one such DocBook XML master, for example.  It's on the WWW, 
and the packages also install it locally, for off-line reading.


M. Pape did some of the manual pages for some operating system's 
versions of daemontools, converting M. Bernstein's HTML pages into 
roff.  For djbwares I converted everything into DocBook XML, and the 
same holds for djbwares as for the nosh toolset.  There is a DocBook XML 
master that one can view in a WWW browser directly (both on-line and 
off-line), generated HTML pages, and generated manual pages readable 
with man. 
http://jdebp.uk./Softwares/djbwares/guide/commands/setuidgid.xml is a 
copy of one such DocBook XML master, for example.  This is the source 
for the "man setuidgid" manual and the source for 
http://jdebp.uk./Softwares/djbwares/guide/setuidgid.html .


I even filled in the manual pages that M. Pape hadn't done and that M. 
Bernstein hadn't originally written in HTML, and updated some of the 
doco.  See 
http://jdebp.uk./Softwares/djbwares/guide/commands/caldate_easter.xml 
and http://jdebp.uk./Softwares/djbwares/guide/commands/dnscache.xml for 
examples of that.

Re: runit patches to fix compiler warnings on RHEL 7

[Jonathan de Boyne Pollard]

Some of those are common.  I looked at similar stuff in daemontools, 
where runit got some of this code from, when I packaged it up with some 
of the other Bernstein softwares some years ago.  However, you have 
missed the point of HASSHORTSETGROUPS.  There's no point in having 
conditionally compiled code selected by it that uses gid_t in both 
codepaths.  If you are going to use gid_t, you do not need the 
HASSHORTSETGROUPS mechanism in its entirety.  Think about what it does.


* http://jdebp.uk./Softwares/djbwares/

In the nosh toolset, I have no such mechanisms.  The code uses the 
 types, with a std::vector for the call to setgroups() 
in setuidgid-fromenv for example.  The only similar mechanism picks 
between the very old waitpid() function and the newer (but still old, 
because it was SVR4) waitid() function.  And only OpenBSD ever needs the 
code to use the former, in practice.

Re: runit patches to fix compiler warnings on RHEL 7

[Jonathan de Boyne Pollard]

Laurent Bercot:

It looks like several distributions have their own version of runit; 
they are maintained by the distros themselves.


Further to all that:  I believe, although things may have changed, that 
the Debian maintainer for runit is open to patches.


* https://tracker.debian.org/pkg/runit

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Casper Ti. Vector]

On Sun, Dec 01, 2019 at 09:47:52PM -0500, Steve Litt wrote:
> Would it be acceptable to you and them to put the binaries in /bin/s6
> and then very early in the boot add /bin/s6 to the path? This isn't a
> lot different from what djb did with /command, except it's not off the
> root, which everyone seems to hate.

Or can we consider the Plan 9 style [1], which searches all relative
paths (in the broad sense, i.e. all which do not begin with `/', `./' or
`../') from $PATH, so we can install chainloaders into /bin/s6 and then
use `s6/cd' to run `/bin/s6/cd' in execline?

[1] 

I fully understand that this convention is not followed in most Unix
shells (except for rc(1) which is from Plan 9, and perhaps some others),
but execline is not a shell, and we can additionally symlink /bin/s6/*
into /bin for backward compatibility.

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

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

Reading more, it seems the answer is yes:


Our replies crossed. Glad you found what you needed in the doc. :)

--
Laurent

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother 
under what name they run.


Right, but I've heard enough people complain about s6's UI that a 
one-stop

wrapper command sounds like a good idea anyway.



ok. i was more about insights into the design of the whole s6-rc toolset.
are the up/down scripts run by a dedicated service from within the supervision
tree? what exactly is the task of the "s6-rc-oneshot-run" and
"s6-rc-fdholder-filler" internal programs ? how is the startup organized,
how are "longruns" and "oneshots" intertwined ?

having to read the sources to get this information is somewhat inconvenient.


 This is exactly what I was saying: I'm not documenting those details
because I don't want to be bound by them. The s6-rc-fdholder-filler API
changed right before 0.2.0.0; making this necessary change would have 
been

a lot more difficult if people had relied on details of the interface.

 If you're doing something that requires knowledge of the internal 
programs,

you're definitely good enough to read the code. :P

--
 Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

OK, great!  I just sent my patch series in a separate reply.  I'm happy
to have a tech discussion about it, and I could possibly change the
patch series based on the discussion, or if it is determined that my
patch series should not be accepted, I would accept that as well.


Eh, "fix old compiler warnings" doesn't require much discussion :)



That's when
I found runit which did support the concept of a service becoming
available with its "sv start" command and a "./check" service script.
This way, I could start it and wait for it to become available before
starting something else.

So, if s6 can do something similar, I'd be happy to try it out!  Can it?


Yes it can, and it does you one better: if your service supports it, s6
can tell you that it's ready as soon as the service says it is, without
the need for polling at all.
(https://skarnet.org/software/s6/notifywhenup.html for the tech 
details.)


And s6 has, for instance, commands that block until a service is ready,
so you can write your startup sequence without "sv check" shenanigans.



I see something called sdnotify-wrapper, so maybe I should have a look
at that?  (It was mentioned to me off-list.)


sdnotify-wrapper will only be useful if your daemon is using the
NOTIFY_SOCKET mechanism (aka sd_notify()) to tell systemd when it is
ready. If it's the case, then yes, you can use sdnotify-wrapper in your
s6 run script and it should automatically do the right thing.

But if you have control over your daemon's source, or the daemon 
supports

it natively (typically via a command line option), the s6 mechanism for
readiness notification is much simpler and lighter. It's just "the
daemon writes a line of text when it's ready, on any file descriptor it
wants, and then closes that file descriptor". For instance, if your
daemon writes "ok" to its stdout when it's ready (and doesn't write
any newline beforehand), you can just use that to inform s6.

And if your daemon doesn't do anything of the sort, you can still poll
it with a "./check" script (or "./data/check" in s6 parlance) as you do
with runit: just prepend your run script with
https://skarnet.org/software/s6/s6-notifyoncheck.html
and your check script will be automatically invoked as necessary, and
the result will be directly piped into the readiness notification
mechanism.

--
Laurent

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

Would it be acceptable to you and them to put the binaries in /bin/s6
and then very early in the boot add /bin/s6 to the path? This isn't a
lot different from what djb did with /command, except it's not off the
root, which everyone seems to hate.


s6 binaries aren't a problem for Debian; but apparently, execline
binaries are. They're doing exactly that: they're storing execline
binaries under /usr/lib/execline - except they're not putting that
directory in the default PATH, they're only adding it to PATH when
execlineb is invoked. Which breaks some s6 commands in older s6 
versions,

and breaks s6-rc commands (any version), because those assume that
execline binaries can be found in their PATH, and don't call execlineb.

It's completely acceptable to me to put binaries in a separate 
directory.

But said separate directory *needs* to be in the default PATH. If it is
not, it means that those binaries are considered second-class citizens,
and that is *not* acceptable - and even more importantly, it breaks
things.



As a guy who has both daemontools and s6 installed on the same box, I
thank you from the bottom of my heart for:

1) Prepending s6- to each command so they don't clash with djb's
2) Except for the s6-, naming them the same as djb's so I have less to
   remember.


Yes, there are a good number of people, me included, who prefer that
naming scheme. However, Jan's UX return is valid, and if I want to make
s6 adoption as easy as possible, it needs to be taken into account too.



A simple change change I think would do it is to change the
documentation to imply that, for the *user*, execlineb is a way to get
just a little extra whatever. Currently, when I read it, I thought I'd
be missing a lot by using /bin/sh.


I think it's already the case, but I'll make a pass on the documentation
to make it abundantly clear.



Does the *user* need to code execline scripts, or is it just
something the program does? If the former, then make a point that one
doesn't need to use execline for s6-rc to be a very powerful startup
system.


 1. execline is used *internally* by s6-rc, in autogenerated scripts. 
The

user doesn't have to know anything about it.

 2. source oneshot up/down scripts are parsed by execlineb, so this is a
place where users interact with it. However, the interaction can be made
pretty minimal if the up/down script just calls a shell script stored
somewhere else (typically /etc/init.d), which is common, and generally
good, practice.
 For instance, the "source/network-interfaces/up" script could simply
contain:

 /etc/init.d/network start

and that's it. Technically, this is an execline script, made of two 
words,
but nobody needs to know that; and the complex logic of the script can 
be

implemented in the /etc/init.d/network program, which can be written in
any language. Even in a compiled language, if you're a masochist.

Advanced users can write more complex logic in the
source/network-interfaces/up script itself, using execline binaries for
control flow, etc. But it's by no means essential. For all intents and
purposes, that script is just a small command line that execs into 
another

script, hosted wherever you want, written in whatever language you want.
So I'd say the necessary interaction between s6-rc users and execline is
really tiny.



If anybody would make an execline tutorial, that would help a lot. For
a guy like me who only does procedural programming (C, C++, Pascal,
Perl, Python, Ruby, Lua, etc), execline is difficult to understand.


Well, for one, the execline documentation is bad (it was my first real
attempt at writing software documentation, and it shows), so revamping 
it

would probably help a lot. And second, there *are* execline tutorials
online, you just haven't looked.

--
Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 12/02, J. Lewis Muir wrote:
> So, if s6 can do something similar, I'd be happy to try it out!  Can it?

Reading more, it seems the answer is yes:

  https://skarnet.org/software/s6/notifywhenup.html

So, s6 has a built-in mechanism where, when the supervised process is
available ("ready" in the s6 nomenclature), it writes a line to a file
descriptor and closes it.

If the supervised process does not support the file descriptor
notification mechanism, a workaround is the s6-notifyoncheck program:

  https://skarnet.org/software/s6/s6-notifyoncheck.html

This all looks promising!  Thank you, Laurent, for writing and
maintaining s6!

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 11/28, Laurent Bercot wrote:
>  - This mailing-list accepts all discussions about process supervision
> software. It also accepts patches to such software (but rather than cold
> sending patches, please engage in a tech discussion first - it doesn't
> have to be long.)

OK, great!  I just sent my patch series in a separate reply.  I'm happy
to have a tech discussion about it, and I could possibly change the
patch series based on the discussion, or if it is determined that my
patch series should not be accepted, I would accept that as well.

>  - The original author or runit is still subscribed to this list, and
> comes from time to time. However, I'm not aware of an official repo for
> runit, and runit's latest official version has been 2.1.2 for many a year
> now.
>  It looks like several distributions have their own version of runit;
> they are maintained by the distros themselves.
> 
>  - We on the list will gladly help with any question with runit, but to
> be honest, I'm not exactly sure what to do with patch upstream requests
> for runit. Is anyone processing them and integrating them into a new
> release?
 
This is unfortunate, but I understand and know that things can happen,
priorities can change, time availability can change, etc.  A proper
upstream would be useful.  A bunch of forks does not seem useful to me.
The versions maintained by distros do not seem useful to me because I
suspect that they would not be interested in patches related to distros
or OSes other than their own.

>  - I host this list. I'm also the author of s6, a supervision software
> suite that is very similar to runit in many ways. s6 is actively
> maintained and has a public git repo, and we generally have a quick
> response time with requests.
> 
>  - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is to
> just switch to s6 - and it comes with several other benefits as well.

OK, I'm open to that.  Thanks for the suggestion!

I don't need an init replacement, and I initially chose daemontools
because it was the original toolset, and I wanted something that could
start and stop a server process that did not daemonize itself.  But
the server that I wanted to manage took a while to actually become
"available," and daemontools didn't support the concept of a service
becoming available sometime after when it was started.  That's when
I found runit which did support the concept of a service becoming
available with its "sv start" command and a "./check" service script.
This way, I could start it and wait for it to become available before
starting something else.

So, if s6 can do something similar, I'd be happy to try it out!  Can it?

My use case is actually to run it as a systemd service, so briefly
looking at

  https://skarnet.org/software/

I see something called sdnotify-wrapper, so maybe I should have a look
at that?  (It was mentioned to me off-list.)

>  - But again, I'm not impartial, and alternatives are a good thing.
> So no matter what individual decisions are made, it would definitely be
> a net positive if the exact state and workflow of runit could be
> clarified, and if a real development/maintenance structure was in place.

+1.  Agreed.

Lewis

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 11/27, Martin Castillo wrote:
> On 27.11.19 21:33, J. Lewis Muir wrote:
> > On 11/25, J. Lewis Muir wrote:
> >> Is runit hosted in a public source code repo?  If so, where?
> >>
> >> Are patches to fix runit compiler warnings on RHEL 7 welcome?
> > 
> > I have patches now.  Is there a public source code repo I can contribute
> > against?  Or would it be helpful to just send the patches to the list?
> 
> AFAIK you have to post them to this list.

OK, attached is the patch series.

To apply it against runit 2.1.2:

$ cd admin/runit-2.1.2
$ patch -p2 < /path/to/runit-2.1.2-rhel-7-compiler-fixes.diff

The patch series eliminates all GCC 4.8.5 warnings on x86_64 RHEL 7.7.
I haven't tested on other platforms, so it could be that some of the
fixes just make it compile cleanly on RHEL 7 but not on other platforms.
If this is the case, then I think more logic would be needed at compile
time to test the available APIs and choose the appropriate APIs to use.

Regards,

Lewis
# HG changeset patch
# User J. Lewis Muir 
# Date 1574790428 21600
#  Tue Nov 26 11:47:08 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID bdaf3416fb1b1010546d8a52b75dc764ca8a80a5
# Parent  6001387b32501dd5c76c969467cf4f7a655e9dcf
Change getgroups arg 2 type in chkshsgr.c to gid_t

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chkshsgr.c
  chkshsgr.c: In function ‘main’:
  chkshsgr.c:10:3: warning: passing argument 2 of ‘getgroups’ from incompatible 
pointer type [enabled by default]
 if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
 ^
  In file included from chkshsgr.c:3:0:
  /usr/include/unistd.h:711:12: note: expected ‘__gid_t *’ but argument is of 
type ‘short int *’
   extern int getgroups (int __size, __gid_t __list[]) __THROW __wur;
  ^

diff -r 6001387b3250 -r bdaf3416fb1b external/src/chkshsgr.c
--- a/external/src/chkshsgr.c   Tue Nov 26 10:48:03 2019 -0600
+++ b/external/src/chkshsgr.c   Tue Nov 26 11:47:08 2019 -0600
@@ -4,7 +4,7 @@
 
 int main()
 {
-  short x[4];
+  gid_t x[4];
 
   x[0] = x[1] = 0;
   if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791174 21600
#  Tue Nov 26 11:59:34 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID a12ee55203125f8ef926dbe72e66a1bd45235619
# Parent  bdaf3416fb1b1010546d8a52b75dc764ca8a80a5
Include grp.h in chkshsgr.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chkshsgr.c
  chkshsgr.c: In function ‘main’:
  chkshsgr.c:10:3: warning: implicit declaration of function ‘setgroups’ 
[-Wimplicit-function-declaration]
 if (getgroups(1,x) == 0) if (setgroups(1,x) == -1) _exit(1);
 ^

diff -r bdaf3416fb1b -r a12ee5520312 external/src/chkshsgr.c
--- a/external/src/chkshsgr.c   Tue Nov 26 11:47:08 2019 -0600
+++ b/external/src/chkshsgr.c   Tue Nov 26 11:59:34 2019 -0600
@@ -1,5 +1,6 @@
 /* Public domain. */
 
+#include 
 #include 
 
 int main()
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791401 21600
#  Tue Nov 26 12:03:21 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID b0034c0716a2f8496d17d5c4a1d8d77193b3594f
# Parent  a12ee55203125f8ef926dbe72e66a1bd45235619
Include grp.h in chpst.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chpst.c
  chpst.c: In function ‘suidgid’:
  chpst.c:80:3: warning: implicit declaration of function ‘setgroups’ 
[-Wimplicit-function-declaration]
 if (setgroups(ugid.gids, ugid.gid) == -1) fatal("unable to setgroups");
 ^

diff -r a12ee5520312 -r b0034c0716a2 external/src/chpst.c
--- a/external/src/chpst.c  Tue Nov 26 11:59:34 2019 -0600
+++ b/external/src/chpst.c  Tue Nov 26 12:03:21 2019 -0600
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "sgetopt.h"
 #include "error.h"
# HG changeset patch
# User J. Lewis Muir 
# Date 1574791671 21600
#  Tue Nov 26 12:07:51 2019 -0600
# Branch 2.1.2_compiler-warning-fixes
# Node ID 396b02da6d0e56256ac5c1cf00ed0af690dbd8f1
# Parent  b0034c0716a2f8496d17d5c4a1d8d77193b3594f
Avoid op sequence order ambiguity in chpst.c

This change eliminates the following GCC 4.8.5 warning on RHEL 7.7:

  ./compile chpst.c
  chpst.c: In function ‘main’:
  chpst.c:312:33: warning: operation on ‘subgetoptarg’ may be undefined 
[-Wsequence-point]
 if (optarg[scan_ulong(++optarg, )]) usage(); nicelvl =ul;
   ^

diff -r b0034c0716a2 -r 396b02da6d0e external/src/chpst.c
--- a/external/src/chpst.c  Tue Nov 26 12:03:21 2019 -0600
+++ b/external/src/chpst.c  Tue Nov 26 12:07:51 2019 -0600
@@ -309,7 +309,8 @@
 case 'n':
   switch (*optarg) {
 case '-':
-  if (optarg[scan_ulong(++optarg, )]) usage(); nicelvl =ul;
+  ++optarg;
+  if (optarg[scan_ulong(optarg, )]) usage

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Jeff]

30.11.2019, 19:58, "Laurent Bercot" :
>> the solution here could be a simple symlink to the original s6 tool without
>> the prefix if you prefer (maybe even located in an other dir than /bin).
>
> That would be a decision for users, not software authors - else it would
> defeat the point of not invading the namespace. Daemontools is still
> around with names such as "svc".

sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother
under what name they run.
 
>> using a single combined tool is more efficient since it avoids wasteful
>> further exec chaining steps, though.
>
> Sure, but if we're talking about UI, optimization at this level is a
> very
> moot point. A human choosing between "chpst" and "s6-applyuidgid" will
> *not* notice the extra millisecond taken by an execve() step. The
> primary focus should be usability.

i prefer short names like "chpst" (change process state ?) with multiple
command line options from a usability perspective. but the usage of single
tools with descriptive names is of course easier to read (not to write) and
hence understand when they occur in a script, that's true.

> I am reluctant to make the ABI details public because I want the freedom
> to change them. If people start relying on internals, their stuff may
> break when updating, which would be bad.
> There are *some* details that I could document as official and stable,
> but I'd need to go through all of it and decide with precision what can
> be guaranteed and what cannot - and that's extra work, so it will have
> to wait.

ok. i was more about insights into the design of the whole s6-rc toolset.
are the up/down scripts run by a dedicated service from within the supervision
tree? what exactly is the task of the "s6-rc-oneshot-run" and
"s6-rc-fdholder-filler" internal programs ? how is the startup organized,
how are "longruns" and "oneshots" intertwined ?

having to read the sources to get this information is somewhat inconvenient.
:-(

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Steve Litt]

On Sat, 30 Nov 2019 10:15:27 +
"Laurent Bercot"  wrote:


> I hear you. Unfortunately, I have no control over what Debian does.
> Debian isn't even able to ship a not-broken execline package, so I'm
> at a loss on what to do with them. I'm working on a version of
> execline that
> they *might* accept to package correctly, but it's doubtful as long as
> the people in charge are prejudiced against the "lots of small
> binaries in /bin" approach. :(

Would it be acceptable to you and them to put the binaries in /bin/s6
and then very early in the boot add /bin/s6 to the path? This isn't a
lot different from what djb did with /command, except it's not off the
root, which everyone seems to hate.

[snip] 

> >3) s6 executables are somehow worse named than runit's. This may be
> >highly subjective, but I can recall and recognize the runit
> > commands far easier than the s6 ones. Possibly it's the "s6-"
> > prefix getting in the way of my brain pattern matching on visual
> > appearance of glyph sequences.
> >This point is exacerbated by #2 and the number of s6 executables.
> >Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
> >s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
> >historical reasons, but still.  
> 
> This is very interesting. I thought that having a s6- prefix was a 
> *good*
> thing, because I valued clarity above everything, and especially above
> terseness. 

As a guy who has both daemontools and s6 installed on the same box, I
thank you from the bottom of my heart for:

1) Prepending s6- to each command so they don't clash with djb's
2) Except for the s6-, naming them the same as djb's so I have less to
   remember.

[snip]
> 
> >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. s6
> depends on execline in two places (there were more, but I scrapped
> them because nobody used the commands that were involved):
> - at build-time, in s6-ftrig-listen
> - at run-time, in s6-log, for processor invocation
> 
> Would entirely removing s6's dependency on execline help clear that
> misunderstanding and help with s6 adoption? This could be made
> possible by:
> - duplicating el_semicolon() functionality in s6-ftrig-listen.c
> (it's not elegant, but clearing the dep may be worth it)
> - adding an alternative '?' processor directive to s6-log, that spawns
> the processor using /bin/sh instead of execlineb. (The '!' directive
> would still be there; processor invocations using '!' would just fail
> if execline is not installed.)
> 
> I don't like this, but if "execline" is a scarecrow that keeps people
> away from s6 for no other reason than perception, it's a possibility.
> Savvy users will still install execline for use in run scripts.

I don't think it's necessary to remove the dependency unless ordinary
users would be altering the code of s6-ftrig-listen or s6-log.

A simple change change I think would do it is to change the
documentation to imply that, for the *user*, execlineb is a way to get
just a little extra whatever. Currently, when I read it, I thought I'd
be missing a lot by using /bin/sh.


> 
> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts. But s6-rc is a different beast, that
> requires a lot more involvement than s6 anyway, and that isn't needed
> at all if we're just talking about runit-like functionality.

Does the *user* need to code execline scripts, or is it just
something the program does? If the former, then make a point that one
doesn't need to use execline for s6-rc to be a very powerful startup
system.

If anybody would make an execline tutorial, that would help a lot. For
a guy like me who only does procedural programming (C, C++, Pascal,
Perl, Python, Ruby, Lua, etc), execline is difficult to understand.

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Jeff]

30.11.2019, 11:15, "Laurent Bercot" :
> This is very interesting. I thought that having a s6- prefix was a *good*
> thing, because I valued clarity above everything, and especially above
> terseness. I understand the advantages of having commands named "sv" and
> "chpst", but I believed, in my naïveté, that it wasn't a good idea for a
> specialized package to tread on a large namespace; and to me the s6-
> prefix would help users recognize exactly the domain of the command
> they're using, and then they could abstract it away and focus on the
> real command name.

totally agreed, Laurent.

using a dedicated namespace prefix like "s6-" is a very good idea.
this avoids nameclashes (i. e. overwriting on installation) with similar
utilities of other supervision suites and frees Laurent from the task
of coming up with proper AND unique command names. consider
nameclashes of several "init" program for example.

the solution here could be a simple symlink to the original s6 tool without
the prefix if you prefer (maybe even located in an other dir than /bin).

> The number of executables is a choice; I like to have more, smaller,
> executables than less, bigger ones. One function, one tool. It makes
> code easier to write; this is not really for historical reasons, it's a
> design choice. Personally, it's easier for me to remember several
> process state change command names than all the options to chpst.
> whenever I use chpst, I always need to check the doc; when I use
> something like softlimit or setuidgid, I may need to check the doc for
> specific options, but I always remember which command I want and its
> general syntax. So, I suppose it comes down to individual preference
> there.

using a single combined tool is more efficient since it avoids wasteful further
exec chaining steps, though.

> Would a generic "s6" command, that takes alternative syntax and rewrites
> itself into "internal" commands, help? It could emulate runit syntax,
> among other things.
>
> s6 runsv ... -> s6-supervise ...
> s6 sv ... -> s6-svc ...
> s6 chpst ... -> various s6-prefixed process state change commands
>
> My plan is for the future s6-frontend package to include such a
> one-stop-shop command that controls various aspects of an s6
> installation,
> but if this command can help with s6 adoption, I can work on it much
> earlier than the rest of the s6-frontend functionality.
>
> Or, if you have other ideas that could help with easier assimilation of
> the s6 commands, I'm very open to suggestions.

Busy/ToyBox style ?

> Would entirely removing s6's dependency on execline help clear that
> misunderstanding and help with s6 adoption? This could be made possible
> by:
> - duplicating el_semicolon() functionality in s6-ftrig-listen.c
> (it's not elegant, but clearing the dep may be worth it)
> - adding an alternative '?' processor directive to s6-log, that spawns
> the processor using /bin/sh instead of execlineb. (The '!' directive
> would still be there; processor invocations using '!' would just fail
> if execline is not installed.)

sounds not too bad, IMO. though i personally can live without it,
especially since the other suites also provide loggers (without any
execline deps of course), he can use dt encore's "multilog" utility.

> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts.

could you document the way s6-rc works (i. e. its architecture) somewhere ?
or are users requested to follow your C code to find out how it works
exactly ?

> But s6-rc is a different beast, that
> requires a lot more involvement than s6 anyway, and that isn't needed
> at all if we're just talking about runit-like functionality.

indeed.

Re: runit patches to fix compiler warnings on RHEL 7

[Jeff]

>>  chpst is a monster of a program and at least with runscripts written in
>>  execline it's generally easier to understand 3-4 process state
>>  manipulators than a pile of chpst options.
>
> this is more complicated to use, though.

it is even unnecessary, inefficient, and wasteful.

why exec chaining into several different utils where doing all the
requested process state changes in one go by using the same
utility to achieve them would suffice ?

Re: runit patches to fix compiler warnings on RHEL 7

[Jeff]

30.11.2019, 01:22, "Colin Booth" :
>>  2) runit has manpages. s6 has HTML. :(
> Yeah, this sucks. I know Laurent isn't going to do it but I've been
> meaning to take some time off and dedicate it to rewriting all of the
> documentation into something that an compile into both mandoc and html.

what about writing the docs in Perl's POD format or Markdown ?
it is easy to convert POD to html AND manpages (pod2(html,man))
and to deliver the generated docs in the source releases.

>>  3) s6 executables are somehow worse named than runit's. This may be
>> highly subjective, but I can recall and recognize the runit commands
>> far easier than the s6 ones. Possibly it's the "s6-" prefix getting
>> in the way of my brain pattern matching on visual appearance of glyph
>> sequences.
>> This point is exacerbated by #2 and the number of s6 executables.
>> Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
>> s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
>> historical reasons, but sti

totally agreed.

> chpst is a monster of a program and at least with runscripts written in
> execline it's generally easier to understand 3-4 process state
> manipulators than a pile of chpst options.

this is more complicated to use, though.
therefore i personally prefer perp's approach of providing both:
the single process state manipulators and their combination into one
single tool ("run..." vs "runtool").

>>  Brainstorming possible ways forward:
>>
>>  A) Gerrit Pape becomes more active in maintianing runit, at least
>> acknowledging patches posted here.
>>  B) Somebody else steps in as (co-)maintainer.
>>  C) We get a dumping ground (wiki or somesuch) for patches to allow
>> - contributors to publish their patches (after discussing them here)
>> - users to easily find and download patches they'd be interested in
>> - Gerrit Pape to review and apply patches at his leisure when he
>>   feels like making a new release.
>>  D) The maintainers of distros shipping runit work out a patch-sharing
>> scheme among them.

runit is dead, i recommend against using it at all, the only tools of interest
this supervision suite provides are "chpst" and "utmpset"
(though the latter is indeed not as powerful as it should to make it really
useful).

besides waking up to poll for rundir changes shutting it down really
sucks since it has problems closing the log files properly, i have not seen
this with any of daemontools encore, perp, and s6.

consider switching, daemontools encore and perp were not meant to run
as process #1, but they can be supervised by (Busy,Toy)Box- or SysV init easily.

daemontools encore's "svscan" utility wakes up to poll the rundir for changes
frequently, though, unlike s6 and perp it does not provide any option to only
do this on request (maybe by just listing for a given signal).

so the final conclusion and recommendation here is:
stop using runit for supervision (and as process #1) and switch to s6.

s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

As a relatively new convert to supervision software, my reasons for
preferring runit over s6 are, in order of priority:


Hi Jan,

Thank you a lot for this feedback. This is very useful UX return.
Let me address the points one by one.



1) Debian ships with a working and maintained runit-init package. It
   provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
   Debian packages. s6-linux-init and s6-rc are not packaged in Debian.


I hear you. Unfortunately, I have no control over what Debian does.
Debian isn't even able to ship a not-broken execline package, so I'm at
a loss on what to do with them. I'm working on a version of execline 
that

they *might* accept to package correctly, but it's doubtful as long as
the people in charge are prejudiced against the "lots of small binaries
in /bin" approach. :(



2) runit has manpages. s6 has HTML. :(


This is far from the first time I hear this, so it would be foolish to
ignore it, but I *really* have a hard time understanding how in 2019 
it's

so difficult for people to launch a browser to read a web page. I just
can't get it. Launching a browser and reading a web page is something 
that
we all do, every day, even the least computer-savvy ones among us, and 
for
the life of me I can't fathom how this is *not* a friendly user 
interface.
HTML even has the advantages of hyperlinks, so you can jump around in 
the

documentation as needed, which you can't do with man pages!

Do you work offline? don't you have access to a web browser? do you like
reading stuff in a terminal *better*? (Text-based web browsers still
exist, if you do.)

It really stumps me. I did learn "man" too, 25 years ago, before the
Web existed. It was nice when man pages were all we had. But a couple of
years later, we had something that seems unarguably better to me, and
I see exactly zero reason to go back, apart from the force of habit of
typing "man".

Nevertheless, if people like man pages, they should have man pages, so
it's been a few years that I have appealed to the community for this.
I'm not going to learn nroff, ever, but we have a relatively large user
community, so they could probably contribute man pages, right? We've had
a few people who seemed interested, some of them even started thinking
about it *really hard*. And one of them even wrote a tool to convert
text into nroff, à la markdown (but simpler). But when it was about 
doing

the actual work of writing the man pages (even if all the material is
already here, in the HTML doc)? You guessed it: crickets.

So, yeah, I want s6 to be accessible, but I figure that if people
really wanted man pages, they'd write man pages ¯\_(ツ)_/¯ Or maybe I was
wrong all along and the spirit of Open Source really is "If the one 
person
doing the work doesn't do exactly what I want, then I'm just gonna sit 
on

my ass and blame them".

If I'm sounding a bit jaded, it's because I am.



3) s6 executables are somehow worse named than runit's. This may be
   highly subjective, but I can recall and recognize the runit commands
   far easier than the s6 ones. Possibly it's the "s6-" prefix getting
   in the way of my brain pattern matching on visual appearance of glyph
   sequences.
   This point is exacerbated by #2 and the number of s6 executables.
   Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
   s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
   historical reasons, but still.


This is very interesting. I thought that having a s6- prefix was a 
*good*

thing, because I valued clarity above everything, and especially above
terseness. I understand the advantages of having commands named "sv" and
"chpst", but I believed, in my naïveté, that it wasn't a good idea for a
specialized package to tread on a large namespace; and to me the s6-
prefix would help users recognize exactly the domain of the command
they're using, and then they could abstract it away and focus on the
real command name.
Now you're saying that the s6- prefix *impedes* your pattern recognition
and detracts you from easily mapping the command name to its 
functionality;

that having it is worse UI than not having it. I had not heard this
before, but it quite makes sense.

The number of executables is a choice; I like to have more, smaller,
executables than less, bigger ones. One function, one tool. It makes
code easier to write; this is not really for historical reasons, it's a
design choice. Personally, it's easier for me to remember several
process state change command names than all the options to chpst.
whenever I use chpst, I always need to check the doc; when I use
something like softlimit or setuidgid, I may need to check the doc for
specific options, but I always remember which command I want and its
general syntax. So, I suppose it comes down to individual preference
there.

Would a generic "s6" command, that takes alternative syntax and rewrites
itself into "internal" commands, help? It could emulate runit syntax,

Re: runit patches to fix compiler warnings on RHEL 7

[Steve Litt]

On Sat, 30 Nov 2019 00:21:59 +
Colin Booth  wrote:

 
> runit-init is slowly becoming less functional and it wouldn't surprise
> me if it fails entirely after Debian 10. 

By what mechanism is runit-init slowly becoming less functional, and
what changes in Debian might cause it to fail entirely?

Thanks,
 
SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Re: runit patches to fix compiler warnings on RHEL 7

[Colin Booth]

On Sat, Nov 30, 2019 at 08:46:28AM +1100, Dewayne Geraghty wrote:
> Jan,
> 
> I'm also a virgin to process/service management software, learning s6-rc,
> s6, execlineb is not for the faint-hearted nor the time-poor. Getting a
> handle on the concepts, and the naming conventions - its really hard work.
If you want to ease yourself into process supervision I suggest starting
just with s6 and a smattering of execline when you are trying to
describe things that are really annoying to express in shell. Usually
you only need to do this when your run scripts are turning into a mess
of line continuations because of the chain load utilities but there are
other reasons to do it as well. 

s6-rc is absolutely not necessary for basic service management. It's a
very nice helper utility when you're mixing non-idempotent oneshots with
long-running services or handling deep dependency tries that are fairly
touchy (like system bootstrap stuff), but if you don't need deep levels
of dependency ordering and any initial environmental setup for a service
can be handled in an idempotent way, s6-rc is intense overkill. If you
need to synchronize between two services, you can hard-code startup and
shutdown dependencies with s6-svwait and/or s6-svc calls reaching into
the other service directory. It's a pretty low-rent but it's very easy
to think about and manage.
> 
> Execline enforces a discipline, a rigor demanding anticipatory planning (to
> get right).  I ran some performance tests and execlineb is marginally
> better.  So why persist?  Largely because an execline script is immediately
> obvious and explicit.  Seriously, at a glance you know what the script will
> achieve.  Could I write a sh script to do the same task?  Yes, and probably
> do it a lot quicker.  But.  I would loose the elegance and readability -
> where sh has an equivalence with assembler, execline is akin to BASIC, it
> makes you think differently :)
I personally like execline for run scripts because there's very little
magic and it takes a lot of work to fail to get the service that you
want supervised correctly parented at the end of the day. Also, since it
execs into each program you end up not having to do shenanigans like
execing into nested shells if you need to modify state after dropping
privileges (like you do with chpst).
> 
> I'm developing solutions for PROTECTED level security (its an Australian
> Govt thing), and skarnet's service management provides assurance, and s6-log
> provides near-certainty of logging completeness. I'm very happy with the
> toolset, worth the time investment.

-- 
Colin Booth

Re: runit patches to fix compiler warnings on RHEL 7

[Colin Booth]

On Fri, Nov 29, 2019 at 03:09:01PM +0100, Jan Braun wrote:
> Hi,
> 
> Laurent Bercot schrob:
> >  - My opinion is that the most sustainable path forward, for runit
> > users who need a centrally maintained supervision software suite, is to
> > just switch to s6 - and it comes with several other benefits as well.
> 
> As a relatively new convert to supervision software, my reasons for
> preferring runit over s6 are, in order of priority:
> 
> 1) Debian ships with a working and maintained runit-init package. It
>provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
>Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
runit-init is slowly becoming less functional and it wouldn't surprise
me if it fails entirely after Debian 10. As for s6-rc and s6-l-i, you
don't need either of those to emulate runit-init and if you do want them
you should talk to the current maintainer of s6 and execline about
adding them.

The rcS.d hooks can be covered with a shim program, though the LSB
compatibility layer in runit is pretty poor to start with and I tend to
suggest people avoid it if they can help it.
> 
> 2) runit has manpages. s6 has HTML. :(
Yeah, this sucks. I know Laurent isn't going to do it but I've been
meaning to take some time off and dedicate it to rewriting all of the
documentation into something that an compile into both mandoc and html.
> 
> 3) s6 executables are somehow worse named than runit's. This may be
>highly subjective, but I can recall and recognize the runit commands
>far easier than the s6 ones. Possibly it's the "s6-" prefix getting
>in the way of my brain pattern matching on visual appearance of glyph
>sequences.
>This point is exacerbated by #2 and the number of s6 executables.
>Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
>s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
>historical reasons, but sti
chpst is a monster of a program and at least with runscripts written in
execline it's generally easier to understand 3-4 process state
manipulators than a pile of chpst options.
> 
> 4) s6 seems more complex (hello execline!), and I don't (yet?) see any
>benefit/feature I'd appreciate except minimizing wakeups.
s6 is more complex in terms of total bits than runit, but that
complexity brings objective benefits like having the supervision system
itself know when supervised services are ready and being able to query
the supervisor for that status. If you're talking about comparisons with
the supervisory portions of runit, besides the differences with chpst
mentioned earlier the two are pretty comparible. As for the execline
dependency, the only place where it's really required is if you use
s6-log processing directives though it's a pretty nice language for
writing run scripts in.
> 
> OTOH, an active and responsive upstream is obviously a big plus for s6.
> 
> >  - But again, I'm not impartial, and alternatives are a good thing.
> > So no matter what individual decisions are made, it would definitely be
> > a net positive if the exact state and workflow of runit could be
> > clarified, and if a real development/maintenance structure was in place.
> 
> Agreed.
> 
> Brainstorming possible ways forward:
> 
> A) Gerrit Pape becomes more active in maintianing runit, at least
>acknowledging patches posted here.
> B) Somebody else steps in as (co-)maintainer.
> C) We get a dumping ground (wiki or somesuch) for patches to allow
>- contributors to publish their patches (after discussing them here)
>- users to easily find and download patches they'd be interested in
>- Gerrit Pape to review and apply patches at his leisure when he
>  feels like making a new release.
> D) The maintainers of distros shipping runit work out a patch-sharing
>scheme among them.
> 
> 
> Just my 0.02€, I hope it helps.
> 
> cheers,
> Jan



-- 
Colin Booth

Re: runit patches to fix compiler warnings on RHEL 7

[Dewayne Geraghty]

Jan,

I'm also a virgin to process/service management software, learning 
s6-rc, s6, execlineb is not for the faint-hearted nor the time-poor. 
Getting a handle on the concepts, and the naming conventions - its 
really hard work.


Execline enforces a discipline, a rigor demanding anticipatory planning 
(to get right).  I ran some performance tests and execlineb is 
marginally better.  So why persist?  Largely because an execline script 
is immediately obvious and explicit.  Seriously, at a glance you know 
what the script will achieve.  Could I write a sh script to do the same 
task?  Yes, and probably do it a lot quicker.  But.  I would loose the 
elegance and readability - where sh has an equivalence with assembler, 
execline is akin to BASIC, it makes you think differently :)


I'm developing solutions for PROTECTED level security (its an Australian 
Govt thing), and skarnet's service management provides assurance, and 
s6-log provides near-certainty of logging completeness. I'm very happy 
with the toolset, worth the time investment.

Re: runit patches to fix compiler warnings on RHEL 7

[Jan Braun]

Hi,

Laurent Bercot schrob:
>  - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is to
> just switch to s6 - and it comes with several other benefits as well.

As a relatively new convert to supervision software, my reasons for
preferring runit over s6 are, in order of priority:

1) Debian ships with a working and maintained runit-init package. It
   provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
   Debian packages. s6-linux-init and s6-rc are not packaged in Debian.

2) runit has manpages. s6 has HTML. :(

3) s6 executables are somehow worse named than runit's. This may be
   highly subjective, but I can recall and recognize the runit commands
   far easier than the s6 ones. Possibly it's the "s6-" prefix getting
   in the way of my brain pattern matching on visual appearance of glyph
   sequences.
   This point is exacerbated by #2 and the number of s6 executables.
   Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
   s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
   historical reasons, but still.

4) s6 seems more complex (hello execline!), and I don't (yet?) see any
   benefit/feature I'd appreciate except minimizing wakeups.

OTOH, an active and responsive upstream is obviously a big plus for s6.

>  - But again, I'm not impartial, and alternatives are a good thing.
> So no matter what individual decisions are made, it would definitely be
> a net positive if the exact state and workflow of runit could be
> clarified, and if a real development/maintenance structure was in place.

Agreed.

Brainstorming possible ways forward:

A) Gerrit Pape becomes more active in maintianing runit, at least
   acknowledging patches posted here.
B) Somebody else steps in as (co-)maintainer.
C) We get a dumping ground (wiki or somesuch) for patches to allow
   - contributors to publish their patches (after discussing them here)
   - users to easily find and download patches they'd be interested in
   - Gerrit Pape to review and apply patches at his leisure when he
 feels like making a new release.
D) The maintainers of distros shipping runit work out a patch-sharing
   scheme among them.


Just my 0.02€, I hope it helps.

cheers,
Jan


signature.asc
Description: PGP signature

runit or s6 (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

For submitting patches, I'd recommend working with the Void Linux
project. They can be found at #xbps on Freenode IRC. Void Linux has
used runit as their init system for the past 5 years: Their
implementation is very reliable and mature.


Yes, but OP wants to fix compiler warnings on RHEL7. Do you think Red 
Hat

uses Void as their runit upstream?



IMHO not necessarily. There are people whose top priority is
simplicity.


You love to prop up the discourse that runit is a lot simpler than s6,
but I reject this assumption, and you're doing a disservice to me *and*
to users by propagating it. Core runit and core s6 are very similar,
and the complex parts of s6 are entirely optional.

The part where runit is definitely simpler than s6 is when both are used
as init systems, which is entirely optional too. Again, OP is talking
about RHEL7: what are the odds runit is used as an *init system* on 
RHEL7?

so the bulk of the "simplicity" argument falls here.



Which leads to the next point: One reason runit has such a large
mindshare is because Void Linux and maybe some others ship with runit
as their init. s6 has an opportunity to leapfrog. Right now, the Devuan
project is discussing supplying run scripts for runit and for s6.


The Devuan people know me well. They know where to contact me. They know
I'm interested in helping as much as I can if they choose s6. I haven't
heard from them. So, I'm assuming they're not really interested.
If I'm wrong, my mailbox is open.



Anyway, if you
have a bunch of known-good s6 run (and finish) scripts curated
somewhere, everyone would be pleased if you let the Devuan user mailing
list know where they are.


 It's been the same tune for years, so please believe that I know it 
well.
*Everybody* is in love with s6 as long as everything is turnkey (read: 
as
long as software authors, who are supposed to provide mechanism, are 
also

providing policy, i.e. doing the work of the distribution). But as soon
as the distribution actually has to *do its job*, stop being lazy, and
write policy scripts, suddenly there's no one around. Crickets.

 I've learned the lesson. I will provide a complete set of init scripts.
And I'm slowly getting to the point where I'll be able to do it. But 
I'll

still need 2 more years, because I need to feed myself, too.

 If more people/distros were *really* interested in this, instead of 
just

nodding their heads and paying lip service as long as they don't have to
lift a finger (yes, I'm looking at you too, Steve), it would go a lot
faster. It would most likely already be done.

 You can help by cutting the nagging.

--
 Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[Steve Litt]

On Thu, 28 Nov 2019 19:04:37 +
"Laurent Bercot"  wrote:

>   - We on the list will gladly help with any question with runit, but
> to be honest, I'm not exactly sure what to do with patch upstream
> requests for runit. Is anyone processing them and integrating them
> into a new release?

For submitting patches, I'd recommend working with the Void Linux
project. They can be found at #xbps on Freenode IRC. Void Linux has
used runit as their init system for the past 5 years: Their
implementation is very reliable and mature.

> 
>   - I host this list. I'm also the author of s6, a supervision
> software suite that is very similar to runit in many ways. s6 is
> actively maintained and has a public git repo, and we generally have
> a quick response time with requests.
> 
>   - My opinion is that the most sustainable path forward, for runit
> users who need a centrally maintained supervision software suite, is
> to just switch to s6 - and it comes with several other benefits as
> well.

IMHO not necessarily. There are people whose top priority is
simplicity. They value simplicity over guaranteeing against a machine
whose supervisor has died, and is now incommunicado. They value
simplicity over PID1's ability to supervise one program; the process
supervisor (did I get that right?). Such people would prefer runit.

Additionally, if a person uses sysvinit as PID1 and only PID1, and puts
"respawn runsvdir" in /etc/inittab, then they do get PID1 supervising
the supervisor.

One other observation: If I wanted the Cadillac of the industry, I'd go
with s6. But on a day to day basis, the Chevy of the industry, runit, is
good enough for the driving I do.

Which leads to the next point: One reason runit has such a large
mindshare is because Void Linux and maybe some others ship with runit
as their init. s6 has an opportunity to leapfrog. Right now, the Devuan
project is discussing supplying run scripts for runit and for s6.
Assuming Debian ship with a working s6 (only has to work as a
supervisor: sysvinit could be PID1), if the s6 run scripts arrive
first, I think s6 would be in a position to become Devuan's default
supervisor a year or two from now. I spoke the preceding sentence as an
individual, not as a member of the Devuan community. Anyway, if you
have a bunch of known-good s6 run (and finish) scripts curated
somewhere, everyone would be pleased if you let the Devuan user mailing
list know where they are.

Thanks,

SteveT

Steve Litt
November 2019 featured book: Manager's Guide to Technical
Troubleshooting Second edition
http://www.troubleshooters.com/mgr

Re: runit patches to fix compiler warnings on RHEL 7

[Laurent Bercot]

 I am reluctant to bring this up because I am not a neutral third party,
but this is frankly a conversation that needs to be had.

 - This mailing-list accepts all discussions about process supervision
software. It also accepts patches to such software (but rather than cold
sending patches, please engage in a tech discussion first - it doesn't
have to be long.)

 - The original author or runit is still subscribed to this list, and
comes from time to time. However, I'm not aware of an official repo for
runit, and runit's latest official version has been 2.1.2 for many a 
year

now.
 It looks like several distributions have their own version of runit;
they are maintained by the distros themselves.

 - We on the list will gladly help with any question with runit, but to
be honest, I'm not exactly sure what to do with patch upstream requests
for runit. Is anyone processing them and integrating them into a new
release?

 - I host this list. I'm also the author of s6, a supervision software
suite that is very similar to runit in many ways. s6 is actively
maintained and has a public git repo, and we generally have a quick
response time with requests.

 - My opinion is that the most sustainable path forward, for runit
users who need a centrally maintained supervision software suite, is to
just switch to s6 - and it comes with several other benefits as well.

 - But again, I'm not impartial, and alternatives are a good thing.
So no matter what individual decisions are made, it would definitely be
a net positive if the exact state and workflow of runit could be
clarified, and if a real development/maintenance structure was in place.

--
 Laurent

Re: runit patches to fix compiler warnings on RHEL 7

[Martin Castillo]

On 27.11.19 21:33, J. Lewis Muir wrote:
> On 11/25, J. Lewis Muir wrote:
>> Is runit hosted in a public source code repo?  If so, where?
>>
>> Are patches to fix runit compiler warnings on RHEL 7 welcome?
> 
> I have patches now.  Is there a public source code repo I can contribute
> against?  Or would it be helpful to just send the patches to the list?

AFAIK you have to post them to this list.

Martin

Re: runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

On 11/25, J. Lewis Muir wrote:
> Is runit hosted in a public source code repo?  If so, where?
> 
> Are patches to fix runit compiler warnings on RHEL 7 welcome?

I have patches now.  Is there a public source code repo I can contribute
against?  Or would it be helpful to just send the patches to the list?

Lewis

runit patches to fix compiler warnings on RHEL 7

[J. Lewis Muir]

Hello!

Is runit hosted in a public source code repo?  If so, where?

Are patches to fix runit compiler warnings on RHEL 7 welcome?

Thank you!

Lewis