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

[Tomasz Czapiewski]

On Tue, 24 Apr 2012, Denys Vlasenko wrote:

> 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.

My BusyBox build contains just minor change (diff in attachment), which TV 
vendor has made on BusyBox 1.2.1 and I keep it on BB upgrades.
But I don't think it should be related.

>
> 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
>

Would you change the code above to log via kmsg so I could read them via 
dmesg?
It's currently quite problematic for me to estabilish serial connection 
(lack of hardware at the moment).

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: busybox-1.20.0.diff.gz
Type: application/octet-stream
Size: 976 bytes
Desc: 
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20120424/12a8870c/attachment.obj>