Re: Runit on tty1

[Richard Downing <richard@langside.org.uk>]

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>