andrew@ramona.UU.NET (Andrew Ernest) (02/24/89)
In the past I've read about people marveling at the fact that going to single user mode with uport V/AT doesn't drop DTR. This has always been a pain for me since systems often call (long distance) while I'm checking the file systems. This evening I discovered a simple little trick to drop DTR which works on my 2.3 system: stty 0 -hupcl < /dev/ttynn where "nn" is the port you want to nuke. I hope someone else finds this useful. Andrew Ernest (andrew@ramona.uu.net)
john@wa3wbu.UUCP (John Gayman) (02/25/89)
In article <459@ramona.UU.NET>, andrew@ramona.UU.NET (Andrew Ernest) writes: > checking the file systems. This evening I discovered a simple little > trick to drop DTR which works on my 2.3 system: > > stty 0 -hupcl < /dev/ttynn > I have been having the same problem with V/386 3.0e. When I go to single user mode to do system backups the DTR goes out for a moment and then comes right back on. Likewise, I have a Hayes SM2400 thats used for outgoing calls only. After using CU, the DTR will remain on. I tried the above command and it acted like single-user mode; the DTR went out breifly and then came back on. However, I tried simply "stty 0 < /dev/ttynn" and this turned of DTR and it stayed off! Thanks for the tip. I'll be using this during backups to avoid unwanted calls. John -- John Gayman, WA3WBU | UUCP: uunet!wa3wbu!john 1869 Valley Rd. | ARPA: john@wa3wbu.uu.net Marysville, PA 17053 | Packet: WA3WBU @ AK3P
bill@ssbn.WLK.COM (Bill Kennedy) (02/26/89)
Not to detract from what the others said about stopping up DTR
in single user mode, but you should also be careful about what
processes you let run via /etc/inittab. The second field spells
out what run levels you want the line to affect.
I've seen some systems who just arbitrarily use 1234 for things
like spawning uugetty's and other things that you clearly don't
want at run level 1 (single user). 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.
--
Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill
internet bill@ssbn.WLK.COM or attmail!ssbn!billjohnl@n3dmc.UU.NET (John Limpert) (02/26/89)
In article <1145@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >I've seen some systems who just arbitrarily use 1234 for things >like spawning uugetty's and other things that you clearly don't >want at run level 1 (single user). Single user mode is run level 's'. There is nothing wrong with using run levels 1..4 for multiuser operation although 2 seems to be typical usage on most systems. -- John A. Limpert UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl
dave@pmafire.UUCP (Dave Remien) (02/27/89)
In article <1145@ssbn.WLK.COM> bill@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@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..."