From owner-freebsd-questions  Mon Jul 31 06:14:03 1995
Return-Path: questions-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id GAA21474
          for questions-outgoing; Mon, 31 Jul 1995 06:14:03 -0700
Received: from starfire.mn.org (starfire.skypoint.net [199.86.32.187])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id GAA21467
          for <questions@FreeBSD.org>; Mon, 31 Jul 1995 06:14:00 -0700
From: john@starfire.mn.org
Received: (from john@localhost)
	by starfire.mn.org (8.6.11/1.1)  id IAA11180
	for questions@FreeBSD.org; Mon, 31 Jul 1995 08:13:22 -0500
Message-Id: <199507311313.IAA11180@starfire.mn.org>
Subject: ppp restart methods
To: questions@FreeBSD.org (FreeBSD questions)
Date: Mon, 31 Jul 1995 08:13:18 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1771      
Sender: questions-owner@FreeBSD.org
Precedence: bulk

I see three basic mechanisms to automatically restarting pppd when a full-
time link is desired.
1) checking periodically (e.g. cron) to see if the link is up, and restarting
   it if it is not.
2) use the -detach option to pppd and have a script in a loop-forever
   restarting it
3) use the "disconnect" option to start a script which forks a process
   to sleep for a few seconds, and then restart the daemon

There are scripts going around which implement #1, and this seems to
have been the "traditional" solution, but it does not appeal to me because
of the granularity of the external test and because of the necessity of
testing all the time for a condition that pppd itself detects quit
accurately.  I am trying to choose between #2 and #3, but I don't really
see a lot which distinguishes them.  I am currently leaning toward #3
for two reasons -- I am not certain that I understand all of the side-
effects of defeating the detach if there is a controlling terminal
involved, this solution doesn't rely on an external process waiting
for it to exit.  The thing that bothers me about #3 is that I am
"misusing" the disconnect feature in that it probably executes this
script in all exit cases, whereas I really only want to execute the
script in cases of external disconnection (HUP) and not when a SIGTERM
has been received, and it will be prudent to include some mechanism
within the script to determine whether or not a restart is actually
desired.  I am currently planning on using a test for the existance
of /etc/nologin to determine whether to restart or not.

Any comments, clarifications, observations, or recommendations will be
welcome.

		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417