On Tue, Apr 24, 2012 at 1:18 PM, Tomasz Czapiewski <xe...@irc.pl> wrote: > On Tue, 24 Apr 2012, Denys Vlasenko wrote: > >> On Tue, Apr 24, 2012 at 11:27 AM, Tomasz Czapiewski <xe...@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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox