[ILUG] [OT] Reconnecting to standard output - Solaris

[Brian Foster]

  | From: "Ciaran Johnston" <cj at nologic.org>
  | Date: Fri, 9 Jan 2004 14:53:54 -0000 (GMT)
  | 
  | Hi folks, and a happy new year to you all.
  | 
  | Here's a tricky one, and apologies for the off-topic nature of the post:

 what's OT about it?  this is, IMHO, the most on-Topic post
 of the last week.  no Kit Cars, pointless distro wars, or
 so on ....   ½ ;-)

  | If I start a process from a shell which runs in the background,
  | the standard output of that shell is tied to that terminal.

 I assume you mean “the standard output (stdout) of the process
 is tied to the (same) terminal‟.  however, just what "tied to‟
 means is opaque....

  | In solaris, if I exit the shell, the background process keeps running,
  | but loses it's tty (ps just shows a ? where once there was "pts/13" or
  | whatever).

 there are c.4 things happening here.  in no particular order:
 1st, the backgrounded process's stdout is still the terminal.
 2nd, the process no longer has a controlling tty (that is what
       the `?' from ps(1) means).
 3rd, in principle, the process got a SIGHUP.
 4th, not sure, but Solaris (probably the init-getty-login chain)
       may have arranged things so any further I/O by the process
       with the terminal will fail.  Linux may have also (I dunno).
        this is a common security measure to prevent (e.g.) the
       theft of passwords by a background process spoofing or
       otherwise interfering with the normal init-getty-login.
 the combined upshot is that output from the process will seem to
 disappear; the process may no longer exist; and if it does, then
 ^C (or whatever yer interrupt character is) will not affect it.

  | Is there any way to reconnect a new terminal to this process,
  | or otherwise get hold of the standard output?

 stdout is still the terminal (point 1).
 I/O may, however, be failing (point 4);
  if so, I suspect you are hosed.
 if you want a new controlling terminal (point 2),
  yes it is possible.  I presume (without looking) that
  Stevens is the best resource to consult here.
 if the process is still alive, then the SIGHUP (point 3)
  is not a worry per se; otherwise, deal with it in the
  usual manner.  Kernighan's original paper on programming
  on Unix is good, albeit slightly dated, resource here
  (speaking from memory).

  | The linux approach appears to be that if the terminal dies so do the
  | children, which is a good bit cleaner IMO. I don't have a linux box here
  | to back this up, though (still trying to get our IT department to stop
  | locking me off the network every time they see a non windows box).

 it (should be) the same.  in the Linux case, the difference is
 probably point 3, the SIGHUP.  it is quite possible it is yer
 shell which is the key issue; some shells cause backgrounded
 children to be immune to SIGHUP, others do not.  as I read the
 bash(1) man page, the backgrounded child is not immune to SIGHUP,
 and so is liable to die on Linux --- which seems to be what you
 are seeing.  this is obviously testable.  and clearly, I am
 assuming yer using bash on Linux.

 on Solaris, I assume you not using bash).  as I recall, both
 the Bourne (sh(1)) and Korn (ksh(1)) shells are like bash,
 but the C-shell (cah(1)) is not.  I could be mistaken here.
 I presume whatever shell you are using on Solaris is making
 the process immune to the SIGHUP; again, this is testable.

  | Thanks in advance,
  | Ciaran.

 not sure how much this helps.
cheers!
	-blf-
--
«How many surrealists does it take to    |  Brian Foster      Montpellier,
 change a lightbulb?  Three.  One calms  |  blf at utvinternet.ie      France
 the warthog, and two fill the bathtub   |    Stop E$$o (ExxonMobile)!
 with brightly-colored machine tools.»   |        http://www.stopesso.com