Runit on tty1

Runit on tty1

[Zachary Kotlarek]

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

Has anyone figured out how to get runit off of tty1 when running on  
linux 2.6.17+ kernels? I see there was a discussion in the list back  
in June/July, but I couldn't find a resolution in the archives.

	Thanks much,
		Zach

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 1919 bytes --]

Re: Runit on tty1

[Richard Downing]

Zachary Kotlarek wrote:
> Has anyone figured out how to get runit off of tty1 when running on
> linux 2.6.17+ kernels? I see there was a discussion in the list back in
> June/July, but I couldn't find a resolution in the archives.
> 
>     Thanks much,
>         Zach

No. We are all just putting up with it.  It's just runit, minit and
others don't seem to suffer from it.

R.

Runit on tty1

[Richard A Downing FBCS CITP]

I have just built a new system (glibc-2.4, gcc04.1.1, linux-2.6.17.1)
with runit-1.5.1.
This seems to be quite stable except that tty1 does not accept ctrl-c -
indeed if /etc/runit/ctrlaltdel exists, this is run when ctrl-c is
pressed on tty1 (and causes a reboot as expected).
Another effect, also only on tty1 is that a long output can be
interrupted by a replay of earlier output, this can be recovered by
switching to another tty and back - nothing is in fact list, it's just
the screen output.
Further investigation reveals that runit, as process 1, is marked by
ps-ef as being on tty1 and the bash process started by getty-1 is marked
as ? for it's TTY.  I suspect this is the problem, as it is quite unlike
my other runit-based systems.
There are no errors in the runsvdir proctitle.

Does anyone have any idea what has gone wrong?

Richard.

Re: Runit on tty1

[Richard Downing]

Richard A Downing FBCS CITP wrote:
> I have just built a new system (glibc-2.4, gcc04.1.1, linux-2.6.17.1)
> with runit-1.5.1.
> This seems to be quite stable except that tty1 does not accept ctrl-c -
> indeed if /etc/runit/ctrlaltdel exists, this is run when ctrl-c is
> pressed on tty1 (and causes a reboot as expected).
> Another effect, also only on tty1 is that a long output can be
> interrupted by a replay of earlier output, this can be recovered by
> switching to another tty and back - nothing is in fact list, it's just
> the screen output.
> Further investigation reveals that runit, as process 1, is marked by
> ps-ef as being on tty1 and the bash process started by getty-1 is marked
> as ? for it's TTY.  I suspect this is the problem, as it is quite unlike
> my other runit-based systems.
> There are no errors in the runsvdir proctitle.
> 
> Does anyone have any idea what has gone wrong?
> 
> Richard.
> 
> 

I've just upgraded to runit-1.6.0, but I have the same problem.  What 
could cause runit to be connected to tty1?

R.

Re: Runit on tty1

[Gerrit Pape]

On Fri, Jun 30, 2006 at 10:10:27AM +0100, Richard Downing wrote:
> Richard A Downing FBCS CITP wrote:
> >Further investigation reveals that runit, as process 1, is marked by
> >ps-ef as being on tty1 and the bash process started by getty-1 is marked
> >as ? for it's TTY.  I suspect this is the problem, as it is quite unlike
> >my other runit-based systems.
> >There are no errors in the runsvdir proctitle.
> >
> >Does anyone have any idea what has gone wrong?
> 
> I've just upgraded to runit-1.6.0, but I have the same problem.  What 
> could cause runit to be connected to tty1?

I'm not sure, sorry.  This is what the runit program does:

 o on startup open /dev/console and set controlling terminal through
    ioctl(ttyfd, TIOCSCTTY, (char *)0) (if possible)
 o forking stage 1, which should have full control of console to start an
   emergency shell for example, runit reopens /dev/console read-write
 o forking stage 2 or 3, runit drops the controlling tty through
    setsid()

See src/runit.c, you could test removing the ioctl(), or adding setsid()
at some place.  Please report back if you happen to find out what's
different on your system.

Thanks, Gerrit.

Re: Runit on tty1

[Charlie Brady]

On Fri, 23 Jun 2006, Richard A Downing FBCS CITP wrote:

> I have just built a new system (glibc-2.4, gcc04.1.1, linux-2.6.17.1)
> with runit-1.5.1.
> This seems to be quite stable except that tty1 does not accept ctrl-c -
> indeed if /etc/runit/ctrlaltdel exists, this is run when ctrl-c is
> pressed on tty1 (and causes a reboot as expected).

What are you running on tty1 and how is it started?

> Another effect, also only on tty1 is that a long output can be
> interrupted by a replay of earlier output, this can be recovered by
> switching to another tty and back - nothing is in fact list, it's just
> the screen output.

I'm sorry, I cannot parse that sentence and I do not know exactly what you 
are describing. Could you try again?

> Further investigation reveals that runit, as process 1, is marked by
> ps-ef as being on tty1 and the bash process started by getty-1 is marked
> as ? for it's TTY.

Is getty-1 a runit supervised process? If so, what is its run script?

>  I suspect this is the problem, as it is quite unlike
> my other runit-based systems.
> There are no errors in the runsvdir proctitle.

I've used the following program to start a well behaved shell on tty1 
under runit supervision. I wouldn't be surprised if not all the magic 
invocations are necessary:

#include <termios.h>
#include <sys/fcntl.h>
#include <sys/ioctl.h>
#include <errno.h>

main(argc, argv)
int     argc;
char    *argv[];
{
     int fd;
     ++argv;
     struct termios tty;

     if (! *argv)
     {
         exit(1);
     }

     /* Clean up */
     ioctl(0, TIOCNOTTY, 0);
     close(0);
     close(1);
     close(2);
     setsid();

     /* Reopen console */
     if ((fd = open("/dev/tts/1", O_RDWR)) < 0) {
             return errno;
     }
     dup2(fd, 0);
     dup2(fd, 1);
     dup2(fd, 2);

     ioctl(0, TIOCSCTTY, 1);
     tcsetpgrp(0, getpgrp());

     /* Set terminal settings to reasonable defaults */
     tcgetattr(0, &tty);

     /* set control chars */
     tty.c_cc[VINTR]  = 3;       /* C-c */
     tty.c_cc[VQUIT]  = 28;      /* C-\ */
     tty.c_cc[VERASE] = 127; /* C-? */
     tty.c_cc[VKILL]  = 21;      /* C-u */
     tty.c_cc[VEOF]   = 4;       /* C-d */
     tty.c_cc[VSTART] = 17;      /* C-q */
     tty.c_cc[VSTOP]  = 19;      /* C-s */
     tty.c_cc[VSUSP]  = 26;      /* C-z */

     /* use line dicipline 0 */
     tty.c_line = 0;

     /* Make it be sane */
     tty.c_cflag &= CBAUD|CBAUDEX|CSIZE|CSTOPB|PARENB|PARODD;
     tty.c_cflag |= CREAD|HUPCL|CLOCAL;

     /* input modes */
     tty.c_iflag = ICRNL | IXON | IXOFF;

     /* output modes */
     tty.c_oflag = OPOST | ONLCR;

     /* local modes */
     tty.c_lflag =
             ISIG | ICANON | ECHO | ECHOE | ECHOK | ECHOCTL | ECHOKE | IEXTEN;

     tcsetattr(0, TCSANOW, &tty);

     execvp(*argv, argv);
     exit(3);
}

Re: Runit on tty1

[Milan P. Stanic]

On Wed, Jul 05, 2006 at 11:08:02AM -0400, Charlie Brady wrote:
> 
> On Fri, 23 Jun 2006, Richard A Downing FBCS CITP wrote:
> 
> >I have just built a new system (glibc-2.4, gcc04.1.1, linux-2.6.17.1)
> >with runit-1.5.1.
> >This seems to be quite stable except that tty1 does not accept ctrl-c -
> >indeed if /etc/runit/ctrlaltdel exists, this is run when ctrl-c is
> >pressed on tty1 (and causes a reboot as expected).
> 
> What are you running on tty1 and how is it started?

I missed the beginning of thread so I'm writing here.

I noticed the same behavior when I switched to Linux 2.6.17
I tried with runit 1.3.1 and 1.5.1 but the behavior is same.
When I revert to Linux 2.6.15 all is OK.

Must be that the something is changed in Linux kernel but I didn't have
time to look at it.

Also, when is user logged on tty1 most non-alpha keys (TAB, arrows ...)
does not work in shell.

Re: Runit on tty1

[Richard Downing]

Milan P. Stanic wrote:
> On Wed, Jul 05, 2006 at 11:08:02AM -0400, Charlie Brady wrote:
>> On Fri, 23 Jun 2006, Richard A Downing FBCS CITP wrote:
>>
>>> I have just built a new system (glibc-2.4, gcc04.1.1, linux-2.6.17.1)
>>> with runit-1.5.1.
>>> This seems to be quite stable except that tty1 does not accept ctrl-c -
>>> indeed if /etc/runit/ctrlaltdel exists, this is run when ctrl-c is
>>> pressed on tty1 (and causes a reboot as expected).
>> What are you running on tty1 and how is it started?
> 
> I missed the beginning of thread so I'm writing here.
> 
> I noticed the same behavior when I switched to Linux 2.6.17
> I tried with runit 1.3.1 and 1.5.1 but the behavior is same.
> When I revert to Linux 2.6.15 all is OK.
> 
> Must be that the something is changed in Linux kernel but I didn't have
> time to look at it.
> 
> Also, when is user logged on tty1 most non-alpha keys (TAB, arrows ...)
> does not work in shell.
> 

Yes, this is correct.  My other machines (all x86) exhibit the same 
behaviour when they are up?graded to 2.6.17 kernels.

Looks like something has changed in the ABI with regards to setsid() or 
the TIOCSCTTY ioctl, But I regret that I'm not programmer enough any 
more to be able to diagnose it.

Note this in the changelog for 2.6.17, it might relate to it:

commit 390e2ff07712468ce6600a43aa91e897b056ce12
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Fri Mar 31 02:31:33 2006 -0800

     [PATCH] Make setsid() more robust

     The core problem: setsid fails if it is called by init.  The effect 
in 2.6.16
     and the earlier kernels that have this problem is that if you do a 
"ps -j 1 or
     ps -ej 1" you will see that init and several of it's children have 
process
     group and session == 0.  Instead of process group == session == 1. 
  Despite
     init calling setsid.

     The reason it fails is that daemonize calls set_special_pids(1,1) 
on kernel
     threads that are launched before /sbin/init is called.

     The only remaining effect in that current->signal->leader == 0 for init
     instead of 1.  And the setsid call fails.  No one has noticed because
     /sbin/init does not check the return value of setsid.

     In 2.4 where we don't have the pidhash table, and daemonize doesn't 
exist
     setsid actually works for init.

     I care a lot about pid == 1 not being a special case that we leave 
broken,
     because of the container/jail work that I am doing.

     - Carefully allow init (pid == 1) to call setsid despite the kernel 
using
       its session.

     - Use find_task_by_pid instead of find_pid because find_pid taking a
       pidtype is going away.

     Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
     Signed-off-by: Andrew Morton <akpm@osdl.org>
     Signed-off-by: Linus Torvalds <torvalds@osdl.org>