Re: runit patches to fix compiler warnings on RHEL 7

2021-02-17 Thread 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

2021-02-17 Thread 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

2019-12-08 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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

2019-12-04 Thread 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: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread Laurent Bercot

Reading more, it seems the answer is yes:


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

--
Laurent



Re: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread 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: runit patches to fix compiler warnings on RHEL 7

2019-12-02 Thread 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

2019-12-02 Thread 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

2019-12-02 Thread 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(); nicelvl =ul;
   nicelvl *=-1;
   break;
 case '+': ++optarg;
# HG 

Re: runit patches to fix compiler warnings on RHEL 7

2019-11-30 Thread 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

2019-11-30 Thread 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.



Re: runit patches to fix compiler warnings on RHEL 7

2019-11-29 Thread 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

2019-11-29 Thread 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

2019-11-29 Thread 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

2019-11-29 Thread 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

2019-11-29 Thread 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


Re: runit patches to fix compiler warnings on RHEL 7

2019-11-28 Thread 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

2019-11-28 Thread 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

2019-11-28 Thread 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

2019-11-27 Thread 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