[1.20.0] getty: setsid: Operation not permitted (dissected)

[Denys Vlasenko]

On Tue, Apr 24, 2012 at 1:18 PM, Tomasz Czapiewski <xeros at irc.pl> wrote:
> On Tue, 24 Apr 2012, Denys Vlasenko wrote:
>
>> On Tue, Apr 24, 2012 at 11:27 AM, Tomasz Czapiewski <xeros at irc.pl> wrote:
>>>
>>> dmesg:
>>> Mon Apr 23 23:16:57 2012: process '/sbin/getty -L ttyS0 115200 vt102'
>>> (pid
>>> 909) exited. Scheduling for restart.
>>>
>>> I'm also getting "getty: setsid: Operation not permitted" when trying to
>>> run
>>> above command from shell.
>>
>>
>> It means that setsid fails. We used to just assume it always succeeds.
>> Which was wrong. For one, successful setsid drops ctty,
>> but failing one does not.
>>
>> setsid fails if getty is started in a way so that it is a process leader,
>> but not a session leader. For one, this is what happens
>> when you run a single command (not a pipe) from interactive shell:
>> it is made a process leader by the shell. That's why getty
>> from interactive shell doesn't work (and probably is not expected to).
>>
>> How do you start your getty? From init? Which init - busybox's?
>
>
> Yes, it's started from init, which is a symlink to the same busybox binary.
> /etc/inittab:
> ::sysinit:/etc/init.d/rcS
> ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt102
> ::ctrlaltdel:/sbin/reboot
> null::shutdown:/bin/umount -a -r
> (changing order of ttyS0 and 115200 arguments doesn't seem to make any
> difference)

This is strange. bbox init always puts its children in their own
sessions (meaning it makes them session leaders). See run()
function in init.c: it does setsid() in the child, immediately
after [v]fork.

Let's verify that.
Can you add a debugging printout in getty_main() here?

        /* Create new session and pgrp, lose controlling tty */
bb_error_msg("pid:%d", getpid());
bb_error_msg("sid:%d", getsid(0));
        pid = setsid();  /* this also gives us our pid :) */
        if (pid < 0) {
...

run it and tell me what do you observe?
-- 
vda