Re: wrong exit code for sv status in lsb mode

2019-03-13 Thread Gerrit Pape
On Tue, Jan 08, 2019 at 08:19:30AM -0800, David Mountney via supervision wrote:
> The error was introduced in commit 5fe1bc773c2d979093fe4b1f3ecbbed5e6acdaf0
> "sv.c: properly format status command's output on failure cases."
> 
> Where the log status is being saved to the same variable as the service
> status. The quick fix would be to not record the log status for now:
> 
> $ git diff src/sv.c
> diff --git a/src/sv.c b/src/sv.c
> index 9003142..1676227 100644
> --- a/src/sv.c
> +++ b/src/sv.c
> @@ -167,7 +167,7 @@ int status(char *unused) {
>}
>else {
>  outs("; ");
> -if (svstatus_get()) { rc =svstatus_print("log"); outs("\n"); }
> +if (svstatus_get()) { svstatus_print("log"); outs("\n"); }
>}
>islog =0;
>flush("");
> $

Thanks for the patch, David.

I'm looking forward to do a maintenance release of runit eventually and
am collecting patches.  I'm about to apply this one, has anyone applied
it already and can provide feedback?

Regards, Gerrit.


Re: wrong exit code for sv status in lsb mode

2019-01-08 Thread Gerrit Pape
Hi,

donations for my free software increased recently, not sure why, but
thanks.

runit upstream sources with history still are available through

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

Below is the diff for sv.c from 2.1.1 to 2.1.2.  Possibly anyone can
spot the error and create a patch if that issue is annoying.

Regards, Gerrit.


$ git diff v2.1.1..v2.1.2 src/sv.c
diff --git a/src/sv.c b/src/sv.c
index d126cee..9003142 100644
--- a/src/sv.c
+++ b/src/sv.c
@@ -41,6 +41,7 @@ unsigned int lsb;
 unsigned int verbose =0;
 unsigned long wait =7;
 unsigned int kll =0;
+unsigned int islog =0;
 struct taia tstart, tnow, tdiff;
 struct tai tstatus;
 
@@ -67,6 +68,7 @@ void fatal2(char *m1, char *m2) {
 void out(char *p, char *m1) {
   buffer_puts(buffer_1, p);
   buffer_puts(buffer_1, *service);
+  if (islog) buffer_puts(buffer_1, "/log");
   buffer_puts(buffer_1, ": ");
   buffer_puts(buffer_1, m1);
   if (errno) {
@@ -153,20 +155,22 @@ int status(char *unused) {
   int rc;
 
   rc =svstatus_get();
-  switch(r) { case -1: if (lsb) done(4); case 0: return(0); }
+  switch(rc) { case -1: if (lsb) done(4); case 0: return(0); }
   rc =svstatus_print(*service);
+  islog =1;
   if (chdir("log") == -1) {
 if (errno != error_noent) {
-  outs("; log: "); outs(WARN);
-  outs("unable to change to log service directory: ");
-  outs(error_str(errno));
+  outs("; ");
+  warn("unable to change directory");
 }
+else outs("\n");
   }
-  else
-if (svstatus_get()) {
-  outs("; "); svstatus_print("log");
-}
-  flush("\n");
+  else {
+outs("; ");
+if (svstatus_get()) { rc =svstatus_print("log"); outs("\n"); }
+  }
+  islog =0;
+  flush("");
   if (lsb) switch(rc) { case 1: done(0); case 2: done(3); case 0: done(4); }
   return(rc);
 }
@@ -305,9 +309,11 @@ int main(int argc, char **argv) {
 acts ="d"; kll =1; cbk = break;
   case 'T':
 acts ="tc"; kll =1; cbk = break;
+  case 't':
+if (!str_diff(action, "try-restart")) { acts ="tc"; cbk = break; }
   case 'c':
 if (!str_diff(action, "check")) { act =0; acts ="C"; cbk = break; }
-  case 'u': case 'd': case 'o': case 't': case 'p': case 'h':
+  case 'u': case 'd': case 'o': case 'p': case 'h':
   case 'a': case 'i': case 'k': case 'q': case '1': case '2':
 action[1] =0; acts =action; break;
   case 's':
@@ -318,6 +324,7 @@ int main(int argc, char **argv) {
 act = cbk =0; break;
   case 'r':
 if (!str_diff(action, "restart")) { acts ="tcu"; cbk = break; }
+if (!str_diff(action, "reload")) { acts ="h"; cbk = break; }
 usage();
   case 'f':
 if (!str_diff(action, "force-reload"))
$ 


On Fri, Jan 04, 2019 at 05:10:13PM -0800, David Mountney via supervision wrote:
> This looks like it's still a problem introduced in runit 2.1.2
> 
> If you have defined a log handler, only the status of the log handler is
> returned by sv status.
> 
> Its not clear to me from the changelog why this change was made.
> 
> I guess, ideally if the service status was successful, you could then also
> check the log status, but as it is now, if the service is down, but the log
> is up, sv status reports all is well for its exit codes.
> 
> I've seen other references to this bug, where projects have reverted to the
> previous runit version: https://github.com/chef/omnibus-software/pull/793
> 
> It would be ideal if we could just get this fixed.
> 
> 
> > From: Fabian Ruff
> > Date: Tue, 18 Aug 2015 23:33:50 +0200
> >  Tue, 18 Aug 2015 23:33:50 +0200
> > Hi,
> > I just noticed that the exit code of sv status in "lsb" mode is not 3 in
> > all cases when
> > the service is "down".
> > The problem arises when a service defines a log handler. In that case the
> > return code
> > of svstatus print for the log process overwrites the return code of
> > svstatus print of
> > the actual supervised process (line 170 of sv.c).
> > Is this intentional? Looks like a bug to me.
> > Kind regards,


Re: [PATCH 1/3] correct typo

2016-09-01 Thread Gerrit Pape
On Tue, Aug 30, 2016 at 01:15:20PM +0200, Laurent Bercot wrote:
> >I will be happy to send a 0/n introductory message (git send-email
> >--compose) for any future proposed series, i was not aware that was the
> >custom here.  Indeed, i wrote this series because i could find no clear
> >instructions for how to propose improvements to runit's codebase.
> 
>  I'm not sure. This is more of a discussion/questions list than a
> patch-sending list; as far as I'm concerned I don't like to receive
> patches without some discussion before or at least a little context, but
> for runit you'd have to check with the new runit maintainer, if there's
> one - Gerrit, before you leave, please designate one, and if the answer
> is "it's maintained by Debian/whateverdistro these days", then we'll know
> the right place to send patches is the Debian/whateverdistro ML (but the
> actual maintainers should still subscribe to our list and read it).

Hi, I'm not leaving, just getting older..  Although runit now has a new
Debian maintainer, I intend to keep my hands on the runit original
upstream package, most probably not applying many changes to it, if at
all.  I consider it very stable and usable.  There's one itch

 https://bugs.debian.org/641632

actually reported by Daniel back then.  A proposed patch is available in
the devground branch in the git repository.  But with this bug we're
actually living for years already, seems to happen very rarely.

> >Alternately, if there's a better way to propose changes than sending
> >mail to this list, i'd be happy to rewrite code.html to document it, but
> >i don't know what it is.
> 
>  I'm sorry I don't have a clearer answer. Until we know more precisely how
> the future of runit is organized, it's kinda in a limbo state.

I'm not against patches to runit, as long as submitters are not
demotivated by the fact that it may take some time for me to respond,
and probably most of the patches won't make it into my git repository.

As I did contributions to git end of 2005 and the years after that, I'd
be fine with submitting patches through the mailing list, as they still
do.  OTOH there's some discussion about the development workflow through
mailboxes on the git list lately

 https://marc.info/?t=14713666535=1=2

Regards, Gerrit.


Re: listen(1): proposed addition to the runit suite

2016-08-22 Thread Gerrit Pape
On Wed, Aug 10, 2016 at 11:58:55AM -0400, Daniel Kahn Gillmor wrote:
> Hi Gerrit and other runit folks--
> 
> I'm working on a new tool that i think would fit well with runit, and i
> was wondering if there is any interest in it as a contribution to the
> runit suite.

Hi Daniel,

I'm sure many runit users are happy with contributions.  I didn't look
at yours in detail because there's limited, close to zero, time free for
me to work on runit improvements.  And I actually don't do releases
these days any more.  Release 2.1.2 in from 2014, 2.1.1 from 2009.

> Also: is there a public revision control system for runit?  I've fetched
> the tarballs but some of the info in the tarballs looks like it might be
> generated from git (e.g. "chpst -V" produces something that looks like a
> git commit id).  I'd be happy to supply changes as patches against a
> canonical git repo, if there is one.

Code history starts with 2001, git was not born at that time.  I used
CVS and later migrated to git, not sure when, shortly after I took over
maintainership of git in Debian I guess.

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

But beware, directory layout, build and release processes are from
around 2001, and might not be as modern as expected ;).

Bets Regards, Gerrit.


Re: Runit debian package fix for Ubuntu 16.04

2016-08-22 Thread Gerrit Pape
On Mon, Jul 25, 2016 at 09:02:22AM +0100, Jonathan de Boyne Pollard wrote:
> Pierre Jacomet:
> 
> >I did a couple of fixes to the debian package installer such that
> >the debian/ubuntu installer deals properly with the dichotomy
> >between systemd and upstart and the fact that they both may be
> >installed in the system at the same time. This was causing the
> >installer to fail in ubuntu 16.04. I have a fix, which involves
> >strictly working with the debian files and wanted to submit it. Is
> >the right place to start here or in some debian or possibly an
> >ubuntu maintainers list?
> >
> 
> See these, which I have already tried to draw M. Pape's attention to
> once already (without a response so far):
> 
> * http://www.mail-archive.com/supervision@list.skarnet.org/msg01224.html
> 
> * http://unix.stackexchange.com/a/284453/5132

I never worked with Ubuntu packages.  But runit in Debian now gets some
improvements, and since Ubuntu is downstream of many packages in Debian,
this might solve this problem too eventually.

Regards, Gerrit.


Re: runit maintenance - Re: patch: sv check should wait when svrun is not ready

2015-06-19 Thread Gerrit Pape
On Thu, Jun 18, 2015 at 06:24:13PM -0700, Buck Evan wrote:
 How would you like to see the layout, build process look? Maybe there's an
 example project you like?
 If it's easy enough for me to try, I'd like to.

First is moving away from slashpackage.  Doing it similar to what
Laurant does in his current projects sounds good to me, but I didn't
look into details.  This even might include moving away from the djblib
(Public Domain files from daemontools included in runit) to skalibs.

Best, Gerrit.


runit maintenance - Re: patch: sv check should wait when svrun is not ready

2015-06-18 Thread Gerrit Pape
Hi all,

I'm around, but currently not very active in my open source activities.

runit started in 2001 and was tracked in CVS.  After I took over Debian
maintainership of git in 2005, I converted the repository to git.  The
complete history is available since then

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

Every here and then I think about doing some work on runit, like
integrating patches, but find the file layout in the repo, the build and
installation process, so archaic that I stop again, most of the time.
It's about 13 years old..

Those two things are the two top items on my TODO list.

Regards, Gerrit.


On Thu, Jun 18, 2015 at 10:35:45AM +, James Byrne wrote:
 Similarly, I have two patches which I submitted to the mailing list in 
 February which I would like to get merged:
 
 http://www.mail-archive.com/supervision@list.skarnet.org/msg00500.html
 
 http://www.mail-archive.com/supervision@list.skarnet.org/msg00501.html
 
 It would be useful if Gerrit could respond to confirm whether he is still 
 accepting patches to runit or planning to do any future releases.
 
 Regards,
 
 James
 
 -Original Message-
 From: supervision@list.skarnet.org [mailto:supervision@list.skarnet.org] On 
 Behalf Of Avery Payne
 Sent: 16 June 2015 18:43
 To: Buck Evan
 Cc: supervision@list.skarnet.org
 Subject: Re: patch: sv check should wait when svrun is not ready
 
 I'm not the maintainer of any C code, anywhere.  While I do host a mirror or 
 two on bitbucket, I only do humble scripts, sorry.  Gerrit is around, he's 
 just a bit elusive.
 
 On 6/16/2015 9:37 AM, Buck Evan wrote:
  I'd still like to get this merged.
 
  Avery: are you the current maintainer?
  I haven't seen Gerrit Pape on the list.
 
  On Tue, Feb 17, 2015 at 4:49 PM, Buck Evan b...@yelp.com 
  mailto:b...@yelp.com wrote:
 
  On Tue, Feb 17, 2015 at 4:20 PM, Avery Payne
  avery.p.pa...@gmail.com mailto:avery.p.pa...@gmail.com wrote:
  
   On 2/17/2015 11:02 AM, Buck Evan wrote:
  
   I think there's only three cases here:
  
1. Users that would have gotten immediate failure, and no
  amount of
   spinning would help. These users will see their error delayed
  by $SVWAIT
   seconds, but no other difference.
2. Users that would have gotten immediate failure, but could
  have gotten
   a success within $SVWAIT seconds. All of these users will of
  course be glad
   of the change.
3. Users that would not have gotten immediate failure. None of
  these
   users will see the slightest change in behavior.
  
   Do you have a particular scenario in mind when you mention
  breaking lots
   of existing installations elsewhere due to a default behavior
  change? I
   don't see that there is any case this change would break.
  snip
 
  Thanks for the thoughtful reply Avery. My background is also
  maintaining business software, although putting it in those terms
  gives me horrific visions of java servlets and soap protocols.
 
   I have to look at it from a viewpoint of what is everything
  else in the system expecting when this code is called.  This
  means thinking in terms of code-as-API, so that calls elsewhere
  don't break.
 
  As a matter of API, sv-check does sometimes take up to $SVWAIT
  seconds to fail.
  Any caller to sv-check will be expecting this (strictly limited)
  delay, in the exceptional case.
  My patch just extends this existing, documented behavior to the
  special case of unable to open supervise/ok.
  The API is unchanged, just the amount of time to return the result
  is changed.
 
   This happens because the use of sv check (child) follows the
  convention of check, and either succeed fast or fail fast, ...
 
  Either you're confused about what sv-check does, or I'm confused about
  what you're saying.
  sv-check generaly doesn't fail fast (except in the special case I'm
  trying to make no longer fail fast -- svrun is not started).
  Generally it will spin for $SVWAIT seconds before failing.
 
   Without that fast-fail, the logged hint never occurs; the
  sysadmin now has to figure out which of three possible services in
  a dependency chain are causing the hang.
 
  Even if I put the above issue aside aside, you wouldn't get a hang,
  you'd get the failure message you're familiar with, just several
  seconds (default: 7) later. The sysadmin wouldn't search any more than
  previously. He would however find that the system fails less often,
  since it has that 7 seconds of tolerance now. This is how sv-check
  behaves already when a ./check script exits nonzero.
 
 
   While this is
   implemented differently from other installations, there are
  known cases
   similar to what I am doing, where people have ./run scripts like
  this:
  
   #!/bin/sh

Re: [PATCH/RFC] Re: logpipe error handling patch

2014-08-08 Thread Gerrit Pape
On Thu, Aug 07, 2014 at 11:39:08AM +0200, Jan Pobrislo wrote:
 On Fri, 1 Aug 2014 05:32:16 +
 Gerrit Pape p...@smarden.org wrote:
  On Wed, Jul 30, 2014 at 03:01:16PM +0200, Jan Pobrislo wrote:
   I was under the assumption that the pipe is left open so you can
   send signals in case the supervised processes have trouble exiting
   the normal way.
  
  The service stopped already in this situation, I'm with Laurent in
  this case.  But not the log service, so its control pipe should stay
  open and commands processed.
 
 Can't it happen the other way around? (log/run exiting and ./run
 being stalled) I didn't dig too deep into runsv code to see if that case
 is handled differently.

This is about runsv behavior when receiving the x command through the
control interface, which only is supported for the main service, not the
log service.  So, no.

  What do you think about this patch?:
  
  
  When runsv is told to exit, it now no longer processes any control
  characters read from the control pipe (it still does for the log
  service).  It waits until the log service has terminated and then
  exits.  The sv program now properly reports this through the
  status command.
 
 Using sv with runsv in wait state:
 * Will I still be able to see PIDs of the processes until they exit?
 * Will I be able to send signals to them using sv kill etc. or will I
   have to extract the PIDs and kill them manually?

In the wait state, the service is down, so there's no pid.  For the
appendant log service you still can use all the functionality of sv.

 * How this interacts with the control scripts?

Nothing should change in this regard.

The devground branch in my git repository has a slightly revised version
of the patch.  I'd be happy to receive feedback, there might still be
some glitches.

Regards, Gerrit.


Re: Update on our progress with Runit.

2014-08-08 Thread Gerrit Pape
On Wed, Aug 06, 2014 at 10:55:15PM +, James Powell wrote:
 Also:
 
 http://www.mail-archive.com/supervision@list.skarnet.org/msg00148.html
 
 This patch was released by Gerrit a while back for logpipe error
 handling.

Hi James,

I adjusted the patch a bit as testing showed a bug.  You can find an
updated version in the devground branch in the git repository.

Regards, Gerrit.


Re: svlogd timestamps fail on OpenBSD 5.5 (snapshot)

2014-07-30 Thread Gerrit Pape
On Tue, Jul 29, 2014 at 10:16:55PM +0200, Jérémie Courrèges-Anglas wrote:
 This is a follow-up for a report sent by Mike in April.  The problem
 here is that on some platforms such as OpenBSD and NetBSD, time_t has
 been enlarged to 64 bits even on ILP32.  Since time_t is already used in
 the runit source code I think that this diff can only make things
 better.
 
   
 http://openbsd.cs.toronto.edu/cgi-bin/cvsweb/~checkout~/ports/sysutils/runit/patches/patch-src_fmt_ptime_c?rev=1.1content-type=text/plain

Thanks Jérémie, applied.


Re: logpipe error handling patch

2014-07-29 Thread Gerrit Pape
On Sat, Jul 26, 2014 at 10:44:18AM +0200, c...@webprojekty.cz wrote:
 Hello, I wrote a patch for how broken filedescriptors when creating child
 are handled. Currently only the child dies, leaving non-working instance of
 runsv in place. My patch makes it kill the parent so the runsv process can
 be respawned properly when it gets to the state in which it can't produce
 working children.

Thanks for the patch, but it works around the bug and doesn't fix its
root cause.  Laurent was correct when analysing this a few years ago,
thanks for that
 http://permalink.gmane.org/gmane.comp.sysutils.supervision.general/2026

Here's how to reproduce:
$ mkdir -p bug/log
$ cat EOT bug/run  chmod 755 bug/run
#!/bin/sh
exec sleep 14
EOT
$ cat EOT bug/log/run  chmod 755 bug/log/run
#!/bin/sh
exec sleep 47
EOT
$ runsv ./bug 
[1] 2016
$ sv x ./bug
$ sv u ./bug
runsv ./bug: fatal: unable to setup filedescriptor for ./run: file descriptor 
not open
...

runsv was told to exit, but does not do so until service and log service
have terminated.  It sent TERM to the service, closed the pipe and so
standard input of the log service, and expects it to terminate now.  If
the log service doesn't do so, and runsv is asked to startup the service
again, that it was previously told to take down and then exit, the bug
accurs as the pipe is no longer available.

Regards, Gerrit.


runit maintenance / development

2014-07-25 Thread Gerrit Pape
Hi Jim,

On Tue, Jul 15, 2014 at 11:21:55PM +, James Powell wrote:
 5. And lastly, we've succeeded in several test phases to determine the
 longevity of a new init system, and have determined Runit passes all
 our current criteria, and now we need help redeploying it out for
 other distributions.

Nice!  I'd like to see runit as an alternative init system in Debian,
but there're hurdles, such as sysvinit backward compatibility I actually
don't want to see in runit.

 The only question I have left is for Gerrit Pape and that is if Runit
 is still under any level of development upstream even if maintenance
 only, and are there any outstanding issues still in need of attention.

I'm around and actively using runit on many machines.  We have some
known minor bugs since years, but there's currently nothing that really
needs to be fixed or changed.

That said, I think about further developing runit every here and then.
The still existing interest in this project actually feels motivating.

Regards, Gerrit.