From owner-freebsd-questions@freebsd.org Thu Nov 9 09:02:19 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7181E6F92D for ; Thu, 9 Nov 2017 09:02:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8D8B7E288 for ; Thu, 9 Nov 2017 09:02:17 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id vA991vVC059151; Thu, 9 Nov 2017 20:01:57 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 9 Nov 2017 20:01:56 +1100 (EST) From: Ian Smith To: Polytropon cc: Edgar Pettijohn , Ernie Luzar , freebsd-questions@freebsd.org Subject: Re: Need help with rc.d script In-Reply-To: <20171109040452.d3c25fe2.freebsd@edvax.de> Message-ID: <20171109185331.B72828@sola.nimnet.asn.au> References: <20171108021900.W9710@sola.nimnet.asn.au> <20171108043726.N72828@sola.nimnet.asn.au> <5A01F758.1050706@gmail.com> <20171109005843.E72828@sola.nimnet.asn.au> <5A0332D1.90509@gmail.com> <20171109013818.GA31584@FreeBSD> <20171109040452.d3c25fe2.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 09:02:19 -0000 On Thu, 9 Nov 2017 04:04:52 +0100, Polytropon wrote: Another night owl, hmm? :) > On Wed, 8 Nov 2017 19:42:36 -0600, Edgar Pettijohn wrote: > > On Wed, Nov 08, 2017 at 11:37:37AM -0500, Ernie Luzar wrote: > > > Ian Smith wrote: > > > > On Tue, 7 Nov 2017 13:11:36 -0500, Ernie Luzar wrote: [..] > > > I tested with and without the enclosing ( and ) on the while loop > > > and it made no difference. No pidfile exists before the "service > > > dynip start" is issued and non exists afterwards. > > I don't believe the rc system can write a pidfile for you. Most of if not all > > of the services being started by the rc system are written in c and take care > > of writing their own pidfile. I suspect you could overcome this by writing a c > > program that does so and executes your script every 10 minutes. Or some form of > > pgrep perhaps. > It's easy to create a pidfile from within the shell script for > the shell itself (and its subshells) as well as for an invoked > external program: > > echo $$ > /var/run/${0##*/}.pid > myprog -foo -bar baz -meow > echo $! > /var/run/myprog.pid In that case - unless myprog daemonised itself? - I believe you'd need: myprog -foo -bar baz -meow & so then $! is specifically the PID of the (now background) myprog > The documentation says: > > $$ Expands to the process ID of the invoked shell. A subshell > retains the same value of $ as its parent. > > $! Expands to the process ID of the most recent background command > executed from the current shell. For a pipeline, the process ID > is that of the last command in the pipeline. > > See "man sh", section "Special Parameters", for details Indeed. I was trying to find out whether or not rc made the pidfile, or one had to do it in the program (here a sh script) being run; as Edgar indicated, seems the program|script needs to do it. Even if rc had done so, for a bg subshell (and not $$) you'd need to overwrite it anyway. I think what's needed here for Ernie's dynip script is like: # setup code .. [..] # repeated loop subshell code, to be left running ( while true; do [..] sleep $delay done ) & echo $! > /var/run/dynip.pid # post PID of bg subshell echo ok or such confirmation # if desired exit 0 # finished startup script Then 'service dynip stop' should find and kill the correct process. I generally go a bit further, finding sometimes that only the sleep in such a loop may get killed - since it's running 99.9%+ of the time - so usually take the trouble so any of the usual signals work to end it: ( done=0 trap "done=1" int quit term # signals set done=1 while [ $done -eq 0 ]; do [..] sleep $delay done; echo `basename $0` killed by signal int, quit or term trap - int quit term # for tidyness, overkill here ) & echo $! > /var/run/dynip.pid # correct PID for external kill exit 0 Consult sh(1) regarding how to trap - and/or block - various signals. cheers, Ian