getty trouble

getty trouble

[Dan Melomedman]

Hello. Thanks for runit, I love it.

'getty' runs fine. 'mingetty' refuses to run though, because it gets
EPERM on a tty open. Any ideas? mingetty used to run fine under SysV
init. This is RH 6.2, with the old getty and mingetty. Thanks.

Re: getty trouble

[Gerrit Pape]

On Thu, Aug 19, 2004 at 01:30:46PM -0400, Dan Melomedman wrote:
> Hello. Thanks for runit, I love it.
> 
> 'getty' runs fine. 'mingetty' refuses to run though, because it gets
> EPERM on a tty open. Any ideas? mingetty used to run fine under SysV
> init. This is RH 6.2, with the old getty and mingetty. Thanks.

Most probably it's because runsv doesn't automatically make a service
run script a process group leader.  Some getties call setsid(2) on their
own, some doesn't.  For those which doesn't, you can use chpst(8) to
change the process state.

 exec chpst -P mingetty ...

Regards, Gerrit.

Re: getty trouble

[Dan Melomedman]

Gerrit Pape wrote:
> On Thu, Aug 19, 2004 at 01:30:46PM -0400, Dan Melomedman wrote:
> > Hello. Thanks for runit, I love it.
> > 
> > 'getty' runs fine. 'mingetty' refuses to run though, because it gets
> > EPERM on a tty open. Any ideas? mingetty used to run fine under SysV
> > init. This is RH 6.2, with the old getty and mingetty. Thanks.
> 
> Most probably it's because runsv doesn't automatically make a service
> run script a process group leader.  Some getties call setsid(2) on their
> own, some doesn't.  For those which doesn't, you can use chpst(8) to
> change the process state.
> 
>  exec chpst -P mingetty ...
> 
> Regards, Gerrit.

Could you please document this fact on the installation page? This issue
cost me a lot of time. Thanks.

-- 
"You can't manage a process intended to produce beautiful things without
knowing what beautiful is. American cars are ugly because American car
companies are run by people with bad taste." -Paul Graham

runsv and process groups (was Re: getty trouble)

[Charlie Brady]

On Fri, 20 Aug 2004, Gerrit Pape wrote:

> On Thu, Aug 19, 2004 at 01:30:46PM -0400, Dan Melomedman wrote:
> > Hello. Thanks for runit, I love it.
> > 
> > 'getty' runs fine. 'mingetty' refuses to run though, because it gets
> > EPERM on a tty open. Any ideas? mingetty used to run fine under SysV
> > init. This is RH 6.2, with the old getty and mingetty. Thanks.
> 
> Most probably it's because runsv doesn't automatically make a service
> run script a process group leader.

Gerrit, have you ever given any thought to runsv doing just that? As is, a 
runit managed system is more vulnerable than it should be to bugs in 
supervised daemons. I've had such a buggy client bring down all of runit 
stage 2. I know this is something which Dan deals with in his daemontools 
FAQ, but I think he gives a non-answer:

 How can I supervise a daemon that kills its process group? When pppd 
 receives a TERM signal, it destroys its entire process group, including 
 svscan and all my other daemons.

 Answer: The best answer is to fix the daemon. It is inexcusable for a 
 program to send signals to a process group that it didn't create. 

His answer is congruent to "programs should not have bugs".

Can you think of any reason why runsv *shouldn't* make the supervised 
process a process group leader? It'd take very little code ...

---
Charlie

Re: runsv and process groups

[Clemens Fischer]

* Charlie Brady:

> Can you think of any reason why runsv *shouldn't* make the supervised
> process a process group leader? It'd take very little code ...

how about this one:  there might be a *vital* service running on the
machine which you *want* to bring the machine down in case it fails.

with the current behaviour, the user can choose to give it its own session
using "chpst -P ..." as an additional option.

  clemens

Re: runsv and process groups

[Charlie Brady]

On 23 Aug 2004, Clemens Fischer wrote:

> * Charlie Brady:
> 
> > Can you think of any reason why runsv *shouldn't* make the supervised
> > process a process group leader? It'd take very little code ...
> 
> how about this one:  there might be a *vital* service running on the
> machine which you *want* to bring the machine down in case it fails.

How likely is that to be the case? Could that problem only be solved by 
keeping the current behaviour?

> with the current behaviour, the user can choose to give it its own session
> using "chpst -P ..." as an additional option.

Sure, but to be safe, you need to do that in every run script. Wouldn't it 
be easier for (nearly) everyone if runsv did it?

---
Charlie

Re: runsv and process groups

[Clemens Fischer]

* 2004-08-23 Charlie Brady:

> On 23 Aug 2004, Clemens Fischer wrote:
>
>> with the current behaviour, the user can choose to give it its own
>> session using "chpst -P ..." as an additional option.
>
> Sure, but to be safe, you need to do that in every run script. Wouldn't
> it be easier for (nearly) everyone if runsv did it?

for me this is about choice, but you certainly have a point.  AFAIC i
prefer the current way and advice in the runsv(8) documentation to add the
"chpst -P ..." bit for the "default case".

  clemens

Re: runsv and process groups

[Charlie Brady]

On 26 Aug 2004, Clemens Fischer wrote:

> * 2004-08-23 Charlie Brady:
> 
> > On 23 Aug 2004, Clemens Fischer wrote:
> >
> >> with the current behaviour, the user can choose to give it its own
> >> session using "chpst -P ..." as an additional option.
> >
> > Sure, but to be safe, you need to do that in every run script. Wouldn't
> > it be easier for (nearly) everyone if runsv did it?
> 
> for me this is about choice,

I don't see how your freedom would be curtailed if runsv's behaviour was a 
little different.

> but you certainly have a point.  AFAIC i prefer the current way and
> advice in the runsv(8) documentation to add the "chpst -P ..." bit for
> the "default case".

The runsv documentation doesn't currently have advice to use "chpst -P
..." in run scripts, and very few of the publicly available run scripts
add that "safety belt". IIUC, your suggestion is that that documentation
is added. Mine is that the bahviour of runsv is changed - I don't accept 
that your proposed scenario is a real-world case, but if it is, I expect 
you can find a simple solution which suits your needs. And if not, then 
you could revert the proposed change in the source code.

I'm still curious about Gerrit's opinion. Is there a good reason why runsv 
doesn't put each run script in a new process group? [Other than the 
obvious reason that that would be different behavior to daemontools].

---
Charlie

Re: runsv and process groups

[Gerrit Pape]

On Thu, Aug 26, 2004 at 01:05:13PM -0400, Charlie Brady wrote:
> On 26 Aug 2004, Clemens Fischer wrote:
> > > it be easier for (nearly) everyone if runsv did it?
> > for me this is about choice,
> I don't see how your freedom would be curtailed if runsv's behaviour was a 
> little different.
Once setsid() is called there's no way back.

> > but you certainly have a point.  AFAIC i prefer the current way and
> > advice in the runsv(8) documentation to add the "chpst -P ..." bit for
> > the "default case".
> The runsv documentation doesn't currently have advice to use "chpst -P
> ..." in run scripts, and very few of the publicly available run scripts
> add that "safety belt". IIUC, your suggestion is that that documentation
> is added. Mine is that the bahviour of runsv is changed - I don't accept 
> that your proposed scenario is a real-world case, but if it is, I expect 
> you can find a simple solution which suits your needs. And if not, then 
> you could revert the proposed change in the source code.

> I'm still curious about Gerrit's opinion. Is there a good reason why runsv 
> doesn't put each run script in a new process group? [Other than the 
> obvious reason that that would be different behavior to daemontools].

Hm, I'm not sure yet.  What do you think about runsvdir running runsv in
a new process group, and not runsv the run script?

Regards, Gerrit.

Re: runsv and process groups

[Paul Jarc]

Gerrit Pape <pape@smarden.org> wrote:
> Once setsid() is called there's no way back.

But there is after setpgid().

> Hm, I'm not sure yet.  What do you think about runsvdir running runsv in
> a new process group, and not runsv the run script?

It depends what kinds of arrangements you want to make possible.  If
you want to allow all processes to be in the same group, then you need
an option to turn off all changing of process groups, and it doesn't
matter where the change happens when it is enabled.  If you want to
allow one service to be in the process group with runsvdir and all the
runsvs, then the change can only happen for the run script, not runsv,
and the script change change its process group back to that of its
parent (setpgid(0, getpgid(getppid()))), perhaps with a new chpst
operation.


paul

Re: runsv and process groups

[Charlie Brady]

On Thu, 26 Aug 2004, Gerrit Pape wrote:

> On Thu, Aug 26, 2004 at 01:05:13PM -0400, Charlie Brady wrote:
> > On 26 Aug 2004, Clemens Fischer wrote:
> > > > it be easier for (nearly) everyone if runsv did it?
> > > for me this is about choice,
> > I don't see how your freedom would be curtailed if runsv's behaviour was a 
> > little different.
> Once setsid() is called there's no way back.

Sure, but if the process is still running root, it can send a signal to
its parent's process group.

> > I'm still curious about Gerrit's opinion. Is there a good reason why runsv 
> > doesn't put each run script in a new process group? [Other than the 
> > obvious reason that that would be different behavior to daemontools].
> 
> Hm, I'm not sure yet.  What do you think about runsvdir running runsv in
> a new process group, and not runsv the run script?

That'd satisfy my concern, which is that a buggy run script or daemon can
easily take down the whole system. That's certainly not the resiliency
which people are looking for when they use supervise/runit. Or at least, 
which I'm looking for.

I have more than an academic interest in this issue, since I've been 
bitten by it in the past.

---
Charlie

Re: runsv and process groups

[Gerrit Pape]

On Thu, Aug 26, 2004 at 04:57:54PM -0400, Paul Jarc wrote:
> Gerrit Pape <pape@smarden.org> wrote:
> > Once setsid() is called there's no way back.
> But there is after setpgid().
Hm, I'm not yet sure about all the implications when changing the
default behavior.

> > Hm, I'm not sure yet.  What do you think about runsvdir running runsv in
> > a new process group, and not runsv the run script?
> 
> It depends what kinds of arrangements you want to make possible.

Primarily I want to address Charlie's concern.  It's true that a buggy
program that kills the process group it didn't create kills the stage 2
runsvdir process, and so causes runit to enter stage 3.  But I think
it's also true that this may be used as a feature as Clement noted; the
runsv and runsvdir programs also can be used independently, and in user
space.  And I don't want to make major changes to the default behavior
of the runit programs in versions 1.0.x.

Having runsvdir create a process group for each runsv process could be
done through a command line option and switched on optionally, it's not
that easy with runsv.  This doesn't solve Dan's trouble with the getty
service though, some getties would still need to be run with chpst -P;
this should be documented.

Thanks for your input, Gerrit.

Re: runsv and process groups

[Gerrit Pape]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Thu, Aug 26, 2004 at 09:06:54PM -0400, Charlie Brady wrote:
> On Thu, 26 Aug 2004, Gerrit Pape wrote:
> > Hm, I'm not sure yet.  What do you think about runsvdir running runsv in
> > a new process group, and not runsv the run script?
> 
> That'd satisfy my concern, which is that a buggy run script or daemon can
> easily take down the whole system. That's certainly not the resiliency
> which people are looking for when they use supervise/runit. Or at least, 
> which I'm looking for.
> 
> I have more than an academic interest in this issue, since I've been 
> bitten by it in the past.

Here's a patch to runsvdir that adds a -P option to run each runsv
process in a new session and process group.  You need to change
/etc/runit/2 or /sbin/runsvdir-start to enable it.

Regards, Gerrit.

[-- Attachment #2: diff1 --]
[-- Type: text/plain, Size: 1258 bytes --]

Index: src/runsvdir.c
===================================================================
RCS file: /var/lib/cvs/runit/src/runsvdir.c,v
retrieving revision 1.15
diff -u -r1.15 runsvdir.c
--- src/runsvdir.c	2 Aug 2004 14:02:46 -0000	1.15
+++ src/runsvdir.c	11 Sep 2004 09:26:26 -0000
@@ -16,7 +16,7 @@
 #include "sig.h"
 #include "ndelay.h"
 
-#define USAGE " dir"
+#define USAGE " [-P] dir"
 #define VERSION "$Id: runsvdir.c,v 1.15 2004/08/02 14:03:08 pape Exp $"
 
 #define MAXSERVICES 1000
@@ -39,6 +39,7 @@
 iopause_fd io[1];
 struct taia stamplog;
 int exitsoon =0;
+int pgrp =0;
 
 void usage () { strerr_die4x(1, "usage: ", progname, USAGE, "\n"); }
 void fatal(char *m1, char *m2) {
@@ -72,6 +73,7 @@
 	warn("unable to set filedescriptor for log service", 0);
     sig_uncatch(sig_hangup);
     sig_uncatch(sig_term);
+    if (pgrp) setsid();
     pathexec_run(*prog, prog, (const char* const*)environ);
     fatal("unable to start runsv ", name);
   }
@@ -174,6 +176,13 @@
 
   progname =*argv++;
   if (! argv || ! *argv) usage();
+  if (**argv == '-') {
+    switch (*(*argv +1)) {
+    case 'P': pgrp =1;
+    case '-': ++argv;
+    }
+    if (! argv || ! *argv) usage();
+  }
 
   sig_catch(sig_term, s_term);
   sig_catch(sig_hangup, s_hangup);