mikes@opel.UUCP (Mike Spindler) (09/06/89)
We're running an AT&T 6386, Sys V 3.2, with the virtual console devices. The consoles seem to be accessable from an interactive session on the console, but we have been successful with running a process from inittab. The process starting in inittab does a system() call to vtlmgr and starts another process, redirecting input and output to/from /dev/vt01. We then have the following scenario: a. /dev/vt01 has a real-time process running in the foreground b. /dev/console has a getty running The user can switch to the /dev/console getty by issuing a <alt><sysreq><h> and log in for an interactive session. Upon logging out, I'd like the console to revert back to the /dev/vt01 display. But... currently the vt driver sees the /dev/vt01 running and asks the user if they want to kill the virtual terminal /dev/vt01, they must answer yes to get out (even though this does not kill the /dev/vt01 process.) Question #1: Is there any way possible to bypass this interactive step? The logged-in user doesn't own the process anyway! Question #2: Has anyone already worked out how to program function keys to work in place of the <alt>-<sysreq> combinations (eg. <alt>-<sysreq>-<f1> also maps to simply <f12>)? Question #3: Has anyone figured out how to start up processes directly from inittab to a virtual terminal? What would really be ideal is to start processes or gettys like we used to under Microport. That is, it seems that the virtual consoles used under 3.2 do not have the capability to be accessed directly by programs started from inittab. Running vtlmgr from inittab is equally dreadful. Please email any suggestions to !uunet!opel!mikes Thanks in advance, Mike Spindler
kdg@nirvo.uucp (Kurt Gollhardt) (09/07/89)
In article <273@opel.UUCP> mikes@opel.UUCP (Mike Spindler) writes: >We're running an AT&T 6386, Sys V 3.2, with the virtual console devices. > >... The process starting in inittab does a system() call to >vtlmgr and starts another process, redirecting input and output >to/from /dev/vt01. Not necessary. The vtlmgr program is strictly for interactive creation of shells on new vts (via, by default, <alt><sysreq><function key>). The main virtual terminal functionality, including switching between (already open) vts, is handled directly in the console driver. >We then have the following scenario: > > a. /dev/vt01 has a real-time process running in the foreground > b. /dev/console has a getty running > >The user can switch to the /dev/console getty by issuing a <alt><sysreq><h> >and log in for an interactive session. This scenario should still hold true w/o invoking vtlmgr from inittab. One thing to watch out for, though: depending on exactly how your program is set up, it may end up with /dev/console as its controlling tty (as shown by "ps") instead of /dev/vt01, even though its input and output (and don't forget stderr) are on /dev/vt01. >Upon logging out, I'd like the console to revert back to the /dev/vt01 >display. But... currently the vt driver sees the /dev/vt01 running >and asks the user if they want to kill the virtual terminal /dev/vt01, >they must answer yes to get out (even though this does not kill the >/dev/vt01 process.) > >Question #1: Is there any way possible to bypass this interactive step? > The logged-in user doesn't own the process anyway! This behavior (checking for other vts on logout) is controlled by the /etc/vtgetty program. If you want to disable it, just change vtgetty to getty in inittab (and /etc/conf/cf.d/init.base). >Question #2: Has anyone already worked out how to program function > keys to work in place of the <alt>-<sysreq> > combinations (eg. <alt>-<sysreq>-<f1> also maps to > simply <f12>)? This is described in gory detail in KEYBOARD(7) in the User's/System Administrator's Reference Manual. For this particular example, you'd use the KDSKBENT ioctl with: kb_table = K_NORMTAB [ unshifted key ] kb_index = 88 [ scan code for <f12> key ] kb_value = K_VTF+1 [ vt switch to vt01 ] >Question #3: Has anyone figured out how to start up processes > directly from inittab to a virtual terminal? What would > really be ideal is to start processes or gettys like > we used to under Microport. You *can* run getty on a virtual terminal. This inittab line works just fine: v4:23:respawn:/etc/getty vt04 console > That is, it seems that the > virtual consoles used under 3.2 do not have the capability > to be accessed directly by programs started from inittab. ANY process anywhere can access a virtual console simply by opening it. If you're going to use it interactively, though, you do have worry about things like controlling tty, process groups, and proper stty settings; but these issues are the same for *any* device which is starting from an uninitialized state. There *is* a program which handles all these setup issues: /usr/bin/newvt. Usage: newvt [-e command] [-n vt number]. If you leave out the command, you get an interactive shell. If you leave out the vt number, you get the first free vt. However, newvt appears not to be useable from inittab, so it may not help you with this specific problem. (I think the reason for this may be that newvt needs to know what tty (e.g. /dev/console) it was run from - for reasons beyond the scope of this article - but when run from inittab, it doesn't have a controlling tty.) > Running vtlmgr from inittab is equally dreadful. Certainly is. Isn't it great that you don't have to? :-) -- Kurt Gollhardt \ Nirvonics, Inc. -- Plainfield, NJ Kurt.Gollhardt@nirvo.uucp /\ Software Design and Consulting ...!rutgers!nirvo!Kurt.Gollhardt / \ "It's all about people; not you and me or him and her, but *us*."