rhg@cpsolv.UUCP (Richard H. Gumpertz) (10/18/89)
I have recently been having problems with UUCICO getting wedged after a session: a program named setgetty is running and eating cycles and getty is not getting started. 1) Has anyone else had this problem? 2) What does setgetty do? 3) What are its arguments? 4) After I kill the hung setgetty, do I have to edit /etc/inittab and then run telinit q or is that what setgetty was supposed to do? If so, how do I retry? 5) Any ideas that might lead me to eliminating the setgetty problem? Any ideas what causes it? 6) I am using 3.51 standard AT&T uucp. Is there anything in the 3.51a update that will help? Will HDB uucp do better? ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ========================================================================== -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================
lenny@icus.islp.ny.us (Lenny Tropiano) (10/19/89)
In article <417@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: |>I have recently been having problems with UUCICO getting wedged after a |>session: |>a program named setgetty is running and eating cycles and getty is not getting |>started. |> |>1) Has anyone else had this problem? .. Yes, those problems are pretty old. I can't remember the specifics, although I believe they were fixed. If they weren't fixed there were public domain version of setgetty (John Milton wrote) that did the same thing. |> |>2) What does setgetty do? |> Basically it puts a :, and removes a : from the /etc/inittab file for a specific port. It will call init q, to tell init that it changed that file. Putting a : in front of a line will basically disable that port (turn off the getty) and removing the : (assuming respawn is there) will turn that port back on. |>3) What are its arguments? |> Usage: setgetty devname state ^^ device (ph0 = ph0, tty000 = 000, tty001 = 001, etc.. ) ^^^ state = 0 off, 1 on |>4) After I kill the hung setgetty, do I have to edit /etc/inittab and then run |> telinit q or is that what setgetty was supposed to do? If so, how do I |> retry? |> Probably because "setgetty devname 1" hung... |>5) Any ideas that might lead me to eliminating the setgetty problem? Any |> ideas what causes it? A malformed /etc/inittab file may hang setgetty. Basically if there is no space in front of a [uu]getty line it *might* lock up uugetty. |>6) I am using 3.51 standard AT&T uucp. Is there anything in the 3.51a update |> that will help? Will HDB uucp do better? |> I don't think the 3.51a fixdisk did anything for this?! Don't remember, it was *ages* ago... I've been running HDB without any problems, and it does use the scripts /usr/bin/geton.sh, /usr/bin/getoff.sh which indirectly call setgetty, without any problems. -Lenny -- | Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 | | lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 | | {ames,pacbell,decuac,hombre,sbcs,attctc}!icus!lenny attmail!icus!lenny | +------- ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 -------+
bamford@cbnewsd.ATT.COM (harold.e.bamford) (10/19/89)
In article <417@cpsolv.UUCP> rhg@cpsolv.uucp (Richard H. Gumpertz) writes: >I have recently been having problems with UUCICO getting wedged after a session: >a program named setgetty is running and eating cycles and getty is not getting >started. This has happened to me, but only when /etc/inittab is not in the standard format. In particular, if you edit the file yourself, and try to enable a line by removing the leading ":", then you are screwed (to use the technical term). Instead, REPLACE the ":" with a space. Works for me. -- Harold
rhg@cpsolv.UUCP (Richard H. Gumpertz) (10/21/89)
In article <988@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >Yes, those problems are pretty old. I can't remember the specifics, although >I believe they were fixed. If they weren't fixed there were public domain >version of setgetty (John Milton wrote) that did the same thing. Anybody out there know anything about the "fixed" setgetty? John Milton maybe? >|>5) Any ideas that might lead me to eliminating the setgetty problem? Any >|> ideas what causes it? > >A malformed /etc/inittab file may hang setgetty. Basically if there is no >space in front of a [uu]getty line it *might* lock up uugetty. My /etc/inittab looks fine: it has a ":" at the beginning of the line in question. Killing the looping setgetty and then running "setgetty 001 1" manually works just fine. I am still curious what is causing the original setgetty to sometimes loop, usually when the system is unattended. Anybody know? -- ========================================================================== | Richard H. Gumpertz rhg@cpsolv.UUCP -or- ...!uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 | ==========================================================================