Pidfile generated by /usr/sbin/daemon not usable by rc.d script

[RW]

On Wed, 1 Jun 2016 22:58:28 +1000 (EST)
Ian Smith wrote:

> On Wed, 1 Jun 2016 12:13:27 +0200, Adam Lindberg wrote:
>  > Sorry for the late reply.
>  > 
>  > What we observed was that the `read _pid _junk < $_pidfile` line
>  > did indeed work on the command line, after sourcing /etc/rc.subr.
>  > For some strange reason it seems not to work from inside the
>  > service script for us.  
> 
> I just had another look at your foo.rcscript attachment, and bounced 
> through all in {/usr/local,}/etc/rc.d for examples.  As RW said
> earlier, 'command=yes' appears unlike all the others, in that it does
> not provide the full pathname of the executable.  I don't know if
> that matters here.

I did misunderstand that. When I saw 'command=yes' it looked like the
OP was trying to treat command as a flag.

 
> Also, none of the others (here) need daemon(8) to run, in background
> or otherwise .. are you sure that you require its functionality for
> 'foo'?

Most daemons were written as such.  daemon(8) is there for those that
weren't or were written in a scripting language that doesn't support
the double fork. 


> For one thing, it seems that daemon keeps the -p pidfile locked
> during execution of the process; might that affect service status,
> stop, etc?

I think the problem is pretty straightforward. If you run this

  read _pid _junk < $_pidfile

and $_pidfile doesn't end in a newline, read will wait for one, just as
it would if you typed in a line and didn't hit return.