shutting off DTR

Dave Remien dave at pmafire.UUCP
Mon Feb 27 10:51:21 AEST 1989


In article <1145 at ssbn.WLK.COM> bill at ssbn.WLK.COM (Bill Kennedy) writes:
> [Stuff about dropping DTR, run states deleted]
>The man page suggests that
>changing from multi-user to single user might kill any processes
>that shouldn't be run, but I've not seen it or tried it.

Changing run states to one in which a process or terminal isn't defined
(i.e., to state 4 where you have a line like

e2:23:respawn:/etc/getty -t 120 tty02 1200

will cause the getty, or shell, or whatever is active on that port to be
killed, including all child processes. This can be quite useful; we have
processes on some of our data acquisition machines that are run
according to what state the system is in. (Not terminal processes, but
data acquisition processes). Doesn't have to be tied to a port, either;
processes can be run from inittab quite happily that have no terminal or
port associated with them. Example:

p1:2:respawn:/where_ever/acquire_data

is what we use (well, the names have been changed to protect the
guilty), and the acquire_data program logs its' errors directly to the
console, but this process has no tty associated with it
(is_a_tty(stdout) returns invalid.

Another example is to have a bunch of tty lines defined in one state,
but not another, then use cron to switch states, allowing those lines to
be active for logins at certain times of the day, but not others. Works
well, security wise.

I realize that this doesn't have much to do with Bill's original
posting, but processes can be managed by going to/from states where they
are/aren't defined in /etc/inittab.


>-- 
>Bill Kennedy  usenet      {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
>              internet    bill at ssbn.WLK.COM   or attmail!ssbn!bill


-- 
Dave Remien - WINCO Computer Engineering Group (only somewhat confused, now)
Work - 208-526-3523 Home - 208-524-1906 UUCP Path: ...!bigtex!pmafire!dave 
"How can you be in two places at once, when you're not anywhere at all..."



More information about the Comp.unix.microport mailing list