Very Computer

MORE INFO:

        I have found the cause is that nohup keeps the standard input
attached to the terminal.  Why nohup does this, and why the use of ksh
with nohup causes the serial line to behave strangely, I don't know.

--
Bruce Momjian                          |  830 Blythe Avenue

  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

I have found under several Unix's that running a job with 'nohup' under
the korn shell on a serial line and* up causes the line to behave
strangely until the nohup completes.

        1) Run ksh as your shell
        2) type         nohup sleep 180 &
        3) hang up the serial line
        4) try to log in again

I have found under HP-UX 9.0
        1) doesn't see my last shell logout ( rather it respawns login)
        2) can't log in a 14.4k modem with error correction
        3) doesn't set ctsxon, rtsxoff upon re-login

Under Sequent Dynix/Ptx1.4
        1) doesn't see my last shell logout ( rather it respawns login)
        2) upon re-dial, the line connects but no login is started

As soon as the 'nohup'ed job finishes, everything works fine.  If my
shell is the bourne shell, everything is fine.  In fact, even if my
primary shell is the korn shell, if I start up a bourne shell before
doing the nohup, everything works fine.

It seems that it is some interaction between 'nohup' and 'ksh' that
causes the tty line to stay open while the 'nohup' is running, even
though 'ps' properly shows the job without a controlling terminal.

        I have found the cause is that nohup keeps the standard input
attached to the terminal.  My only solution has been to install the
BSD/Net2 nohup and add a line close the standard input if it a tty.

Why nohup does this, and why the use of ksh with nohup causes the serial
line to behave strangely, I don't know.

Any ideas what is going on here?

--
Bruce Momjian                          |  830 Blythe Avenue

  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

nohup ... </dev/null &

  I assume that the serial line behaves "strangely", because nohup keeps
it open and hence the terminal driver can not do a "hang up on last
close" (see information on HUPCL in termio(7)).

  I hope this helps.

Frank Slootweg, HP, Dutch Customer Response Center.

P.S. I advise you to fix your e-mail addresses, both in the header and
     in your "signature". ".uucp" is not a valid domain.

If you have a job control shell, then it will leave stdin connected,
but the OS should perform a vhangup (from BSD) type of operation
when the originator of the session logs out, leaving the stdin
connected to the internal equivalent of /dev/null.

If your process is _never_ to read stdin, you can also win with

        nohup ... <&- &

which tells a (bourne) shell to close stdin completely!

Hope this helps too!
--

PHONE:  +61-2-698-2322  "I'm waiting for X-Windows to become just that;
FAX:    +61-2-699-9174   Ex-Windows" - A McGrath.

: This sounds more like a shell gotcha than nohup. It's usually silly
: to run "nohup command" without an "&" on the end. Most shells will
: redirect stdin to somewhere other than the terminal when you start
: something in the background.

: If you have a job control shell, then it will leave stdin connected,
: but the OS should perform a vhangup (from BSD) type of operation
: when the originator of the session logs out, leaving the stdin
: connected to the internal equivalent of /dev/null.

Ah, now we are getting somewhere.  Your suggestion that stdin under ksh
is kept connected to the terminal for use in job control seems to be
right on the mark.

While I have patched nohup, I have found another program that seems to
do the same thing, so it does seem to have something to do with how the
korn shell closes (or fails to close) the standard input when the
session leader logs out.

Can someone who has ksh source check into this?  I guess I am wondering
how a bug like this could exist for this long.  Both ksh and nohup are
relatively mature.

Don't people use nohup and ksh on these machines, and get wierd serial
port problems?
--
Bruce Momjian                          |  830 Blythe Avenue

  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

As Chris suggested, the problem is in the job control portion of ksh (or
the kernel).

This morning on the Sequent, I tried the same test with ksh and the
original nohup, but I first turned off job control in the shell with
'set +m'.  Everything worked as it should.

On the HP-UX 9.0 machine, turning off job control in ksh made no
difference.  The serial line still acted strange.

Chris is completely correct that the problem was not nohup.  My hacked
up nohup was merely a workaround for the ksh job control bug.  Other
programs (i.e. Informix On-line's tbinit) when started from a serial
line and left running after hangup also wacked out the serial line.

(Informix's tbinit ignores signals on its own, it doesn't use nohup.
Actually, running tbinit with my hacked up nohup that closes stdin does
prevent tbinit from messing up the line, even if job control is in
effect.)

As everyone at the Sequent site runs the same .kshrc, and no one needs
job control, I put the 'set +m' in .kshrc, and that fixes it.

The HP 9000 machine is still a problem.  'Set -m' doesn't help there.
--
Bruce Momjian                          |  830 Blythe Avenue

  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

: : This sounds more like a shell gotcha than nohup. It's usually silly
: : to run "nohup command" without an "&" on the end. Most shells will
: : redirect stdin to somewhere other than the terminal when you start
: : something in the background.

: : If you have a job control shell, then it will leave stdin connected,
: : but the OS should perform a vhangup (from BSD) type of operation
: : when the originator of the session logs out, leaving the stdin
: : connected to the internal equivalent of /dev/null.

: Ah, now we are getting somewhere.  Your suggestion that stdin under ksh
: is kept connected to the terminal for use in job control seems to be
: right on the mark.

I ran into this problem of ksh leaving stdin connected to the tty a while back.
I was trying to write a ksh script for our Command Center computer operators
which should always be launched in the backgroud with an '&', so as not to tie
up the system console.  The only easy (I thought) way I could find out if they
indeed started the job properly was to check and see if stdin was not a tty.
Then I discovered that ksh is not 100% compatible with sh in this area;  ksh
redirects stdin from /dev/null (ala sh), for a job started in the background
with '&', if, and only if, job control is turned off (+/-m or set -o monitor).

Since we did not want to disable job control for our operators, I ended up
abandoning the portion of the ksh script which was to do this checking for
running in the background.  Has anybody discovered a different way to handle
this ?
--
Perry Lovill    Consultant/System Administrator         Lanier Worldwide, Inc.

exec < /dev/null

at the start of the script, this will ensure that stdin is attached
to /dev/null right at the start.

--
Brian Blackmore, The University of Kent at Canterbury, United Kingdom.
"'I shall sit here,' he said, 'on and off, for days and days'" -- Lewis Carroll

: > Since we did not want to disable job control for our operators, I
: > ended up abandoning the portion of the ksh script which was to do
: > this checking for running in the background.  Has anybody
: > discovered a different way to handle this ?

: If you are prepared to modify the script itself you can always try..

: exec < /dev/null

: at the start of the script, this will ensure that stdin is attached
: to /dev/null right at the start.

The point was, we needed to check if the script was launched in the
background.  This would be determined by whether the human operator in
our Data Center remembered to type the '&' at the end of the command line.
The matter of stdin being connected to /dev/null only came into play via
attempting to test if the job was actually "in the background".

Thanks for the suggestion, but it doesn't apply here.
--
Perry Lovill    Consultant/System Administrator         Lanier Worldwide, Inc.

  I think that you will have to give more details about what exactly you
mean by "The serial line still acted strange." and to give some more
details like series and model, type of serial interface, major/minor
number (and lssf(1M) info if Series 800), "stty -a", fuser(1M) and
"ps -fl" (for the related processes) information before and after the
nohup(1), etc. Only in that way, this audience can try to reproduce your
problem, try to find its cause and try to find a solution/workaround.

Frank Slootweg, HP, Dutch Customer Response Center.

Quote:>Soap-box mode:
>The only generic solution to this problem is to make sure that the old
>BSD vhangup works again! That way, the stdin (or whatever) gets
>internally redirected to the equivalent of /dev/null when the process
>group/session leader dies, or the terminal device hangs up. This
>requires kernel support - only the kernel finds out that the session
>leader is dead, and only the kernel can find all the remaining procs
>(which have ignored the SIGHUP) and do the vhangup for them. Only the
>kernel can then mark the device as idle/unowned.
>One for Sequent or USG/Novell I think (or does Posix specify this
>bogosity too!).

Tim