[ale] After 15 years, Nohup is sttll broken???

[Ed Cashin]

Many years ago I was looking into this and found out that the problem was
that the whole process group was getting killed, as a feature.  So to get
the process to persist when the ssh session went away, I had to dissociate
the process of interest from its process group.

The most straightforward way to do it using only the shell was to force the
process to get owned by init by creating a sub-shell (to serve as a
temporary parent) that immediately exited, e.g., the parentheses syntax
creates a subshell that exits as soon as the sleep starts in the background.

(/bin/sleep 100 < /dev/null > /dev/null 2>&1 &)

Yes, screen or tmux or daemonizing does it, too.


On Wed, Jul 31, 2019 at 11:01 AM Lightner, Jeffrey via Ale <ale at ale.org>
wrote:

> I gather you're doing an ssh from one system to another.   I wonder if
> your shell default on either the system you're coming from or the second
> system has TMOUT variable set and it is thinking the session is idle due to
> lack of output.   If so, doing an unset TMOUT might solve it.   Note I have
> seen issues where firewall devices will timeout sessions such as VPN but I
> can full them by running a while loop in another window to just display
> data to the screen every 5 minutes.
>
> As posted by someone else I typically run:
> nohup <script> &
>
> The nohup tells it not to send a hang-up (hup) when the terminal closes.
> The & tells it to background.
> This runs well for me when I run it from an internal Linux workstation to
> a Linux server in our remote data center.   There is no firewall in between
> so other than insuring TMOUT isn't set I've not needed to do anything to
> leave jobs running overnight.
>
> If all that doesn't work, then screen is the way to go.   It isn’t that
> hard to use or train others to use.
>
>
> P.S.  Retiring after leaving someone with the soon to be EOLed RHEL6 (Or
> CentOS6) on a new install is a dirty trick IMHO :p
>
>
>
>
>
>
>
> *From:* Ale <ale-bounces at ale.org> *On Behalf Of *Chris Fowler via Ale
> *Sent:* Wednesday, July 31, 2019 10:52 AM
> *To:* neal at mnopltd.com
> *Cc:* Atlanta Linux Enthusiasts <ale at ale.org>
> *Subject:* Re: [ale] After 15 years, Nohup is sttll broken???
>
>
>
>
>
>
> ------------------------------
>
> *From: *neal at mnopltd.com
> *To: *"Chris Fowler" <cfowler at outpostsentinel.com>
> *Cc: *"Atlanta Linux Enthusiasts" <ale at ale.org>
> *Sent: *Wednesday, July 31, 2019 10:45:20 AM
> *Subject: *Re: [ale] After 15 years, Nohup is sttll broken???
>
> Thank you for the reply.  Additional response inline below.
>
> On 2019-07-31 09:19, Chris Fowler wrote:
> > -------------------------
> >
> >> FROM: "Neal Rhodes via Ale" <ale at ale.org>
> >> TO: "Jim Kinney" <jim.kinney at gmail.com>
> >> CC: "Atlanta Linux Enthusiasts" <ale at ale.org>
> >> SENT: Wednesday, July 31, 2019 10:10:41 AM
> >> SUBJECT: Re: [ale] After 15 years, Nohup is sttll broken???
> >
> >> Well, indirectly - if the ssh session didn't die, it probably
> >> wouldn't
> >> happen.
> >  I've been using keepalive SSH options for years to keep session up.
> > I had system that did dialout ppp to servers with an idle timeout set
> > for pppd.  SSH session would drop so I used the keep alive out of band
> > SSH messages to keep those connections up.  I now use the same options
> > for standard networks (real speeds).
>
> Hmm.  I forgot about that.   However, the man page for ssh_config states
> that tcpkeepalive is  on by default.  So...
>
> I think we're seeing the ssh sessions die because the Sonicwall VPN is
> configured to kill any connections after xx time.   I cannot get that
> changed.
>
> Dumb NAT firewall.  SSH will NOT send any traffic unless there is traffic
> to send.  If SSH is your only connection then the dumb NAT firewawll will
> only see packets duing standard TCP keep alive or when SSH sends data.  To
> fix that firewall you need to tell SSH to send data!
>
>
>
>
>
> ssh -o ServerAliveInterval=20 -o ServerAliveCount=5 user at host
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>


-- 
  Ed Cashin <ecashin at noserose.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20190731/a4d4804b/attachment.html>