Need help with rc.d script

[Polytropon]

On Thu, 9 Nov 2017 20:01:56 +1100 (EST), Ian Smith wrote:
> On Thu, 9 Nov 2017 04:04:52 +0100, Polytropon wrote:
> 
> Another night owl, hmm? :)

Idiotic "standby time"... ;-)



>  > 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

Good observation. Of course a PID cannot be obtained usefully after
a program has finished running. :-)



>  > 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.

That is correct. While the individual rc script often define
a variable called pidfile (either with a specific hardcoded
name or one depending on variable evaluation), they do not
create it. In /etc/rc.subr, you can find subroutines to be
used by said rc script that can _check_ for a PID file. There
is a whole bunch of PID-related and process-related utility
functions.



> 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.

Correct. If the rc script defines the pidfile variable, the rc-related
tools (for example service, or by calling the rc.d script itself with
the "stop" or "restart" parameter) can use it.



> 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.

A useful idea, especially for debugging and diagnostics.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...