Probems opening /dev/tty when running from gmenu2x

Alan Post alanpost at sunflowerriver.org
Sat Dec 25 12:23:46 EST 2010


On Sat, Dec 25, 2010 at 04:20:28PM +0100, David Kuehling wrote:
> >>>>> "Xiangfu" == Xiangfu Liu <xiangfu at sharism.cc> writes:
> 
> > Hi I fight with this issue two days. but I just don't find a good
> > solution.
> 
> > any help will be great.
> 
> > when we run 'ash' 'bash' in gmenu2x it's always give me : /bin/ash :
> > can't access tty; job control is turned off when start 'ash' 'bash'
> > (http://en.qi-hardware.com/wiki/OpenWrt_Software_Image#Image_2010-12-14
> > see the * KNOWN ISSUES)
> 
> Ok, after lots of trial and error, I now have a fix that works.  It is
> *ugly*, need to clean it up a bit, but anyways:
> 
> Insert this befor execlp:
> --8<--
> 		for (int i = 3; i < 1024; i++) 
> 		   close(i);
> 
> 		int pid = setsid();
> 		int fd = open("/dev/tty0", O_RDWR);
> 		tcsetpgrp(fd, pid);
> 		ioctl(fd, TIOCSCTTY, (char *)1);
> 
> 		dup2(fd, 0);
> 		dup2(fd, 1);
> 		dup2(fd, 2);
> 		close(fd);
> --8<--
> (you also need the <sys/ioctl.h> header)
> 

The value 1024 in the for loop closing all of the >=3 file
descriptors should be determined through calling getrlimit
with the RLIMIT_NOFILE parameter.  And if you're being extra
careful, take the min of 3 and the value getrlimit returns
for you initial condition on that loop, to prevent integer
overflow while looping.  ;-)

If for some reason the open() call fails, it will return -1,
causing each of the dup2 calls to also fail, leaving them
open when execpl is called.  The return value should be checked
if that behavior is a problem.

-Alan
-- 
.i ko djuno fi le do sevzi




More information about the discussion mailing list


interactive